linux PF_PACKET compatibility
Da Rock
protocol family has been introduced, named PF_PACKET. This family allows
an application to send and receive packets dealing directly with the
network card driver, thus avoiding the usual protocol stack-handling
(e.g., IP/TCP or IP/UDP processing). That is, any packet sent through
the socket will be directly passed to the Ethernet interface, and any
packet received through the interface will be directly passed to the
application."
I've been chasing the answer to a FreeBSD version of this (approx.
anyway), but I needed to find out what exactly PF_PACKET was first.
Finally found this answer here: http://www.linuxjournal.com/article/4659
I looked up man socket and I can see possibilities (in my mind anyway),
but I thought I'd be best to check if the gurus here might have a better
idea. My reason for this is I'm attempting to build l2tpns (which
supposedly builds on 7.3?! with no trouble), and I'm chasing the errors
which appear to be linuxisms mostly.
So in man socket simply looking at the list of protocol families I'd say
network driver level would be similar to PF_LINK link layer interface?
Is there another man page I should be looking at as well?
FWIW my gmake output is this:
gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I.
-I/usr/include -I/usr/local/include -DLIBDIR='"/lib/l2tpns"'
-DETCDIR='"/etc/l2tpns"' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER
-DHAVE_EPOLL -DBGP -c -o arp.o arp.c
arp.c: In function 'sendarp':
arp.c:34: error: storage size of 'sll' isn't known
arp.c:59: error: 'PF_PACKET' undeclared (first use in this function)
arp.c:59: error: (Each undeclared identifier is reported only once
arp.c:59: error: for each function it appears in.)
arp.c:62: error: 'AF_PACKET' undeclared (first use in this function)
arp.c:34: warning: unused variable 'sll'
gmake: *** [arp.o] Error 1
I posted this over at -questions@ but it was suggested to try here
instead (or -net@). I figured this would be the best place to start... :)
Cheers
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
Julian Elischer
> "In recent versions of the Linux kernel (post-2.0 releases) a new
> protocol family has been introduced, named PF_PACKET. This family
> allows an application to send and receive packets dealing directly
> with the network card driver, thus avoiding the usual protocol
> stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any
> packet sent through the socket will be directly passed to the
> Ethernet interface, and any packet received through the interface
> will be directly passed to the application."
>
> I've been chasing the answer to a FreeBSD version of this (approx.
> anyway), but I needed to find out what exactly PF_PACKET was first.
> Finally found this answer here:
> http://www.linuxjournal.com/article/4659
>
> I looked up man socket and I can see possibilities (in my mind
> anyway), but I thought I'd be best to check if the gurus here might
> have a better idea. My reason for this is I'm attempting to build
> l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm
> chasing the errors which appear to be linuxisms mostly.
>
> So in man socket simply looking at the list of protocol families I'd
> say network driver level would be similar to PF_LINK link layer
> interface? Is there another man page I should be looking at as well?
We don't have an exact equivalent.. but we have ways of doing the
same thing.
one way that is suggested is to use pcap and bpf which I am pretty
certain has been enhanced to allow sending as
well as receiving.
you can also hook directly to the interface using netgraph(4)
there are other ways too but those are the two that came to mind
immediately.
Vlad Galu
freebsd...@herveybayaustralia.com.au> wrote:
> "In recent versions of the Linux kernel (post-2.0 releases) a new protocol
> family has been introduced, named PF_PACKET. This family allows an
> application to send and receive packets dealing directly with the network
> card driver, thus avoiding the usual protocol stack-handling (e.g., IP/TCP
> or IP/UDP processing). That is, any packet sent through the socket will be
> directly passed to the Ethernet interface, and any packet received through
> the interface will be directly passed to the application."
>
> I've been chasing the answer to a FreeBSD version of this (approx. anyway),
> but I needed to find out what exactly PF_PACKET was first. Finally found
> this answer here: http://www.linuxjournal.com/article/4659
>
> I looked up man socket and I can see possibilities (in my mind anyway), but
> I thought I'd be best to check if the gurus here might have a better idea.
> My reason for this is I'm attempting to build l2tpns (which supposedly
> builds on 7.3?! with no trouble), and I'm chasing the errors which appear to
> be linuxisms mostly.
>
> So in man socket simply looking at the list of protocol families I'd say
> network driver level would be similar to PF_LINK link layer interface? Is
> there another man page I should be looking at as well?
>
> FWIW my gmake output is this:
>
> gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I.
> -I/usr/include -I/usr/local/include -DLIBDIR='"/lib/l2tpns"'
> -DETCDIR='"/etc/l2tpns"' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER -DHAVE_EPOLL
> -DBGP -c -o arp.o arp.c
> arp.c: In function 'sendarp':
> arp.c:34: error: storage size of 'sll' isn't known
> arp.c:59: error: 'PF_PACKET' undeclared (first use in this function)
> arp.c:59: error: (Each undeclared identifier is reported only once
> arp.c:59: error: for each function it appears in.)
> arp.c:62: error: 'AF_PACKET' undeclared (first use in this function)
> arp.c:34: warning: unused variable 'sll'
> gmake: *** [arp.o] Error 1
>
> I posted this over at -questions@ but it was suggested to try here instead
> (or -net@). I figured this would be the best place to start... :)
>
> Cheers
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>
Take a look at bpf(4). I believe you could bypass the TCP/IP stack with
netgraph(4), as well, although with possibly more overhead.
--
Good, fast & cheap. Pick any two.
Da Rock
> On 2/10/11 11:22 PM, Da Rock wrote:
>> "In recent versions of the Linux kernel (post-2.0 releases) a new
>> protocol family has been introduced, named PF_PACKET. This family
>> allows an application to send and receive packets dealing directly
>> with the network card driver, thus avoiding the usual protocol
>> stack-handling (e.g., IP/TCP or IP/UDP processing). That is, any
>> packet sent through the socket will be directly passed to the
>> Ethernet interface, and any packet received through the interface
>> will be directly passed to the application."
>>
>> I've been chasing the answer to a FreeBSD version of this (approx.
>> anyway), but I needed to find out what exactly PF_PACKET was first.
>> Finally found this answer here: http://www.linuxjournal.com/article/4659
>>
>> I looked up man socket and I can see possibilities (in my mind
>> anyway), but I thought I'd be best to check if the gurus here might
>> have a better idea. My reason for this is I'm attempting to build
>> l2tpns (which supposedly builds on 7.3?! with no trouble), and I'm
>> chasing the errors which appear to be linuxisms mostly.
>>
>> So in man socket simply looking at the list of protocol families I'd
>> say network driver level would be similar to PF_LINK link layer
>> interface? Is there another man page I should be looking at as well?
>
> same thing.
> one way that is suggested is to use pcap and bpf which I am pretty
> certain has been enhanced to allow sending as
> well as receiving.
> you can also hook directly to the interface using netgraph(4)
> there are other ways too but those are the two that came to mind
> immediately.
can't fathom how this howto could even exist for l2tpns on FreeBSD if it
isn't even close to buildable... weird!
http://kuapp.com/2010/07/14/how-to-setup-l2tpipsec-vpn-on-freebsd.html
Thanks guys. I'll probably come back with more problems as I slowly
crack this one... :)
Vlad Galu
I suppose you could just use mpd :)
--
Good, fast & cheap. Pick any two.
Da Rock
>
>
> On Fri, Feb 11, 2011 at 11:36 AM, Da Rock
> <freebsd...@herveybayaustralia.com.au
Seriously, though, mpd didn't quite cut it (I thought) for me. I need a
l2tp vpn server with the capability to handle multiple clients with only
one interface. The server is behind a firewall, and I'm trying for a
"walled garden" variety I guess. So far my research has brought me here,
but I'm open to suggestions.
One other that has my attention is l2tpd (in ports). I want radius auth,
so IF I can use pppd in base and radius (which as I understand- so far
anyway- it needs), and only uses a single interface, then maybe.
I'm still hunting and playing- learning on the fly. From what I read mpd
uses an ng interface for every single client. L2tpns doesn't, and from
what I've read so far neither does l2tpd (I was actually looking at
another fork of that xl2tpd). I could use some advice from someone with
experience with this, but my feelers on -questions didn't get much
response. I may try on -net if this fails...
Aside from that I also wanted to get a bit more of a hands on feel for
the FreeBSD core. I can't sit on the sidelines yelling at the players
any more :) I'm not much for spectator sport either...
Julian Elischer
nothing in that page needs to talk to the network interface
directly... what do you think does?
>>
>>
>>>
>>> FWIW my gmake output is this:
>>>
>>> gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I.
>>> -I/usr/include -I/usr/local/include -DLIBDIR='"/lib/l2tpns"'
>>> -DETCDIR='"/etc/l2tpns"' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER
>>> -DHAVE_EPOLL -DBGP -c -o arp.o arp.c
>>> arp.c: In function 'sendarp':
>>> arp.c:34: error: storage size of 'sll' isn't known
>>> arp.c:59: error: 'PF_PACKET' undeclared (first use in this function)
>>> arp.c:59: error: (Each undeclared identifier is reported only once
>>> arp.c:59: error: for each function it appears in.)
>>> arp.c:62: error: 'AF_PACKET' undeclared (first use in this function)
>>> arp.c:34: warning: unused variable 'sll'
>>> gmake: *** [arp.o] Error 1
>>>
>>> I posted this over at -questions@ but it was suggested to try here
>>> instead (or -net@). I figured this would be the best place to
>>> start... :)
>>>
>>> Cheers
Julian Elischer
> On 02/11/11 19:54, Vlad Galu wrote:
>>
>>
>> On Fri, Feb 11, 2011 at 11:36 AM, Da Rock
>> <freebsd...@herveybayaustralia.com.au
> I could, I guess. But where's the fun in that? :)
>
> Seriously, though, mpd didn't quite cut it (I thought) for me. I
> need a l2tp vpn server with the capability to handle multiple
> clients with only one interface. The server is behind a firewall,
> and I'm trying for a "walled garden" variety I guess. So far my
> research has brought me here, but I'm open to suggestions.
why do you think you need only one interface?
>
> One other that has my attention is l2tpd (in ports). I want radius
> auth, so IF I can use pppd in base and radius (which as I
> understand- so far anyway- it needs), and only uses a single
> interface, then maybe.
pppd in base will I think give you multiple interfaces..
>
> I'm still hunting and playing- learning on the fly. From what I read
> mpd uses an ng interface for every single client. L2tpns doesn't,
> and from what I've read so far neither does l2tpd (I was actually
> looking at another fork of that xl2tpd). I could use some advice
> from someone with experience with this, but my feelers on -questions
> didn't get much response. I may try on -net if this fails...
again, whats' with the single interface?
>
> Aside from that I also wanted to get a bit more of a hands on feel
> for the FreeBSD core. I can't sit on the sidelines yelling at the
> players any more :) I'm not much for spectator sport either...
_______________________________________________
Da Rock
> directly... what do you think does?
directly with the network driver sending data to and from the app.
Unfortunately this software uses this family instead of pcap or bpf. So
when built it errors.
I guess if I am to use this app I will have to rewrite the way it uses
the network stack.
>
>
>
>>>
>>>
>>>>
>>>> FWIW my gmake output is this:
>>>>
>>>> gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I.
>>>> -I/usr/include -I/usr/local/include -DLIBDIR='"/lib/l2tpns"'
>>>> -DETCDIR='"/etc/l2tpns"' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER
>>>> -DHAVE_EPOLL -DBGP -c -o arp.o arp.c
>>>> arp.c: In function 'sendarp':
>>>> arp.c:34: error: storage size of 'sll' isn't known
>>>> arp.c:59: error: 'PF_PACKET' undeclared (first use in this function)
>>>> arp.c:59: error: (Each undeclared identifier is reported only once
>>>> arp.c:59: error: for each function it appears in.)
>>>> arp.c:62: error: 'AF_PACKET' undeclared (first use in this function)
>>>> arp.c:34: warning: unused variable 'sll'
>>>> gmake: *** [arp.o] Error 1
>>>>
>>>> I posted this over at -questions@ but it was suggested to try here
>>>> instead (or -net@). I figured this would be the best place to
>>>> start... :)
>>>>
>>>> Cheers
Da Rock
> On 2/11/11 5:40 AM, Da Rock wrote:
>> On 02/11/11 19:54, Vlad Galu wrote:
>>>
>>>
>>> On Fri, Feb 11, 2011 at 11:36 AM, Da Rock
>>> <freebsd...@herveybayaustralia.com.au
>> I could, I guess. But where's the fun in that? :)
>>
>> Seriously, though, mpd didn't quite cut it (I thought) for me. I need
>> a l2tp vpn server with the capability to handle multiple clients with
>> only one interface. The server is behind a firewall, and I'm trying
>> for a "walled garden" variety I guess. So far my research has brought
>> me here, but I'm open to suggestions.
>
> why do you think you need only one interface?
>
>>
>> One other that has my attention is l2tpd (in ports). I want radius
>> auth, so IF I can use pppd in base and radius (which as I understand-
>> so far anyway- it needs), and only uses a single interface, then maybe.
>
> pppd in base will I think give you multiple interfaces..
>>
>> I'm still hunting and playing- learning on the fly. From what I read
>> mpd uses an ng interface for every single client. L2tpns doesn't, and
>> from what I've read so far neither does l2tpd (I was actually looking
>> at another fork of that xl2tpd). I could use some advice from someone
>> with experience with this, but my feelers on -questions didn't get
>> much response. I may try on -net if this fails...
>
> again, whats' with the single interface?
(including mpd - use and ng interface) I will have an net interface for
every client. Apparently l2tpns doesn't do that, and one of the
arguments for its use is that feature. If one has say 100 clients, each
of those needs to be managed- 1 sounds better to me :)
I am only working on theory here so far though, so please let me know if
I'm on the wrong track.
Cheers
>>
>> Aside from that I also wanted to get a bit more of a hands on feel
>> for the FreeBSD core. I can't sit on the sidelines yelling at the
>> players any more :) I'm not much for spectator sport either...
>
Julian Elischer
and routing is more straight forward.
you can do tcpdump on a particular interface or filter on just one
interface.
there have been people with > 100 interfaces.. who didn't seem to
have any problems.
there are advantages and disadvantages.
Julian Elischer
> On 02/12/11 02:37, Julian Elischer wrote:
>> directly... what do you think does?
> I'm afraid you have me a little stumped. The PF_PACKET family talks
> directly with the network driver sending data to and from the app.
>
> Unfortunately this software uses this family instead of pcap or bpf.
> So when built it errors.
>
> I guess if I am to use this app I will have to rewrite the way it
> uses the network stack.
I have no idea why they want raw packets.
talk to the writer of the web page you indicated.. maybe he can help..
>>
>>
>>
>>>>
>>>>
>>>>>
>>>>> FWIW my gmake output is this:
>>>>>
>>>>> gcc -Wall -Wformat-security -Wno-format-zero-length -g -O3 -I.
>>>>> -I/usr/include -I/usr/local/include -DLIBDIR='"/lib/l2tpns"'
>>>>> -DETCDIR='"/etc/l2tpns"' -DSTATISTICS -DSTAT_CALLS -DRINGBUFFER
>>>>> -DHAVE_EPOLL -DBGP -c -o arp.o arp.c
>>>>> arp.c: In function 'sendarp':
>>>>> arp.c:34: error: storage size of 'sll' isn't known
>>>>> arp.c:59: error: 'PF_PACKET' undeclared (first use in this
>>>>> function)
>>>>> arp.c:59: error: (Each undeclared identifier is reported only once
>>>>> arp.c:59: error: for each function it appears in.)
>>>>> arp.c:62: error: 'AF_PACKET' undeclared (first use in this
>>>>> function)
>>>>> arp.c:34: warning: unused variable 'sll'
>>>>> gmake: *** [arp.o] Error 1
>>>>>
>>>>> I posted this over at -questions@ but it was suggested to try
>>>>> here instead (or -net@). I figured this would be the best place
>>>>> to start... :)
>>>>>
>>>>> Cheers
Da Rock
>
> talk to the writer of the web page you indicated.. maybe he can help..
(I'll merge the 2 threads of this to make it easier and less consuming)
>>>again, whats' with the single interface?
>>To be honest I don't know. But from what I've read up on it
so far (including mpd - use and ng interface) I will have an net
interface for every client. Apparently l2tpns doesn't do that,
and one of the arguments for its use is that feature. If one has
say 100 clients, each of those needs to be managed- 1 sounds
better to me :)
I am only working on theory here so far though, so please let me
know if I'm on the wrong track.
>if you have multiple interfaces you can set differnt mtus for them
etc.
and routing is more straight forward.
you can do tcpdump on a particular interface or filter on just one
interface.
there have been people with > 100 interfaces.. who didn't seem to
have any problems.
there are advantages and disadvantages.
I'd say you're right. But if you have all those interfaces (and this
what my first thought was when I started this) then it requires more
holes in the firewall- right? So for every ng interface I'd need to
accept 1701, which gets messy in PF because I'd have to dictate where to
rdr every incoming 1701.
OTOH, if I have just a tun device for every 1701 to connect to then I
only have to rdr all 1701 to the l2tp server. Routing can be done just
on that server (mostly to reroute back out again) either through ppp
static routing or otherwise.
At least this is my impression so far. By all means let me know if I'm
idiot with my head on backwards- I'm trying to get beyond theory before
I start chatting on the -net list... :)
Gary Jennejohn
Julian Elischer <jul...@freebsd.org> wrote:
> On 2/11/11 4:03 PM, Da Rock wrote:
> > Unfortunately this software uses this family instead of pcap or bpf.
> > So when built it errors.
> >
> > I guess if I am to use this app I will have to rewrite the way it
> > uses the network stack.
> l2tp runs over UDP packets (port 1701 (like the starship enterprise))
> I have no idea why they want raw packets.
>
Ther's a sendarp() routine which uses PF_PACKET to directly access the
network driver and bypass the stack. Lazy Linuxers who have no idea
or don't care that other operating systems exist.
--
Gary Jennejohn
Da Rock
> On Fri, 11 Feb 2011 17:19:17 -0800
> Julian Elischer<jul...@freebsd.org> wrote:
>
>
>> On 2/11/11 4:03 PM, Da Rock wrote:
>>
>>> Unfortunately this software uses this family instead of pcap or bpf.
>>> So when built it errors.
>>>
>>> I guess if I am to use this app I will have to rewrite the way it
>>> uses the network stack.
>>>
>> l2tp runs over UDP packets (port 1701 (like the starship enterprise))
>> I have no idea why they want raw packets.
>>
>>
> Ther's a sendarp() routine which uses PF_PACKET to directly access the
> network driver and bypass the stack. Lazy Linuxers who have no idea
> or don't care that other operating systems exist.
>
>
had a look yet as I just read the message, but can I (after checking
return values and arguments) just drop in another arp routine? Or are
they simply incompatible across the board?
From what I understand they should all be essentially doing the same
thing, but I could be wrong on this. Alternatively would I have to
basically rewrite the arp.c to be posix compatible (for portability)?
Cheers
Vlad Galu
freebsd...@herveybayaustralia.com.au> wrote:
> On 02/12/11 19:39, Gary Jennejohn wrote:
>
>> On Fri, 11 Feb 2011 17:19:17 -0800
>> Julian Elischer<jul...@freebsd.org> wrote:
>>
>>
>>
>>> On 2/11/11 4:03 PM, Da Rock wrote:
>>>
>>>
>>>> Unfortunately this software uses this family instead of pcap or bpf.
>>>> So when built it errors.
>>>>
>>>> I guess if I am to use this app I will have to rewrite the way it
>>>> uses the network stack.
>>>>
>>>>
>>> l2tp runs over UDP packets (port 1701 (like the starship enterprise))
>>> I have no idea why they want raw packets.
>>>
>>>
>>>
>> Ther's a sendarp() routine which uses PF_PACKET to directly access the
>> network driver and bypass the stack. Lazy Linuxers who have no idea
>> or don't care that other operating systems exist.
>>
>>
>>
> Indeed. Is it possible to leverage another compatible routine? I haven't
> had a look yet as I just read the message, but can I (after checking return
> values and arguments) just drop in another arp routine? Or are they simply
> incompatible across the board?
>
> From what I understand they should all be essentially doing the same thing,
> but I could be wrong on this. Alternatively would I have to basically
> rewrite the arp.c to be posix compatible (for portability)?
>
> Cheers
>
You only need to rewrite the sendarp() routine, using a BPF device
descriptor instead of the PF_PACKET socket descriptor. Take a look at
libdnet[1] and rbootd[2]'s source.
[1] http://libdnet.sf.net/
[2] http://ftp.fr.openbsd.org/pub/OpenBSD/src/usr.sbin/rbootd/
You will need, however, to fill the source with #ifdefs to compensate the
fact that Linux has assigned different names and sizes to the members of
struct ether_header and arphdr (and has a _BSD_SOURCE knob to accomodate
compiling BSD-based software).* *
--
Good, fast & cheap. Pick any two.
Da Rock
>
>
> On Sat, Feb 12, 2011 at 12:28 PM, Da Rock
> <freebsd...@herveybayaustralia.com.au
>
> On 02/12/11 19:39, Gary Jennejohn wrote:
>
> On Fri, 11 Feb 2011 17:19:17 -0800
> Julian Elischer<jul...@freebsd.org
Ok, I think I know where I have this thing ass-backwards now: I was
looking for similar structs with the same _size_- they don't have to be!
Duh!
I've figured the out the members like ETH_ALEN and defined the bsd
equivalent, I'll have to look into the _BSD_SOURCE.
Thx for the recorrect :)