Re: [maybe spam] Re: linux PF_PACKET compatibility

[Da Rock]

On 02/13/11 06:15, Vlad Galu wrote:



On Sat, Feb 12, 2011 at 12:28 PM, Da Rock 
> wrote:


On 02/12/11 19:39, Gary Jennejohn wrote:

On Fri, 11 Feb 2011 17:19:17 -0800
Julian Elischermailto: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)./ /
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 :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [maybe spam] Re: linux PF_PACKET compatibility

[Vlad Galu]

On Sat, Feb 12, 2011 at 12:28 PM, Da Rock <
freebsd-hack...@herveybayaustralia.com.au> wrote:

> On 02/12/11 19:39, Gary Jennejohn wrote:
>
>> On Fri, 11 Feb 2011 17:19:17 -0800
>> Julian Elischer  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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [maybe spam] Re: linux PF_PACKET compatibility

[Da Rock]

On 02/12/11 19:39, Gary Jennejohn wrote:

On Fri, 11 Feb 2011 17:19:17 -0800
Julian Elischer  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
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [maybe spam] Re: linux PF_PACKET compatibility

[Gary Jennejohn]

On Fri, 11 Feb 2011 17:19:17 -0800
Julian Elischer  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
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [maybe spam] Re: linux PF_PACKET compatibility

[Da Rock]

On 02/12/11 11:19, Julian Elischer wrote:

On 2/11/11 4:03 PM, Da Rock wrote:

On 02/12/11 02:37, Julian Elischer wrote:

On 2/11/11 1:36 AM, Da Rock wrote:

On 02/11/11 18:17, Julian Elischer wrote:

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?


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.
So I'm going to have to rewrite that interface entirely? Bugger! I 
just 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... :)



nothing in that page needs to talk to the network interface 
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.

l2tp runs over UDP packets  (port 1701 (like the starship enterprise))
I have no idea why they want raw packets.

Neither do I.


talk to the writer of the web page you indicated.. maybe he can help..

I did. No response so far... It was for 7.3, but I can't see the difference.

(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... :)











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' undeclare

Re: [maybe spam] Re: linux PF_PACKET compatibility

[Julian Elischer]

On 2/11/11 4:03 PM, Da Rock wrote:

On 02/12/11 02:37, Julian Elischer wrote:

On 2/11/11 1:36 AM, Da Rock wrote:

On 02/11/11 18:17, Julian Elischer wrote:

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?


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.
So I'm going to have to rewrite that interface entirely? Bugger! I 
just 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... :)



nothing in that page needs to talk to the network interface 
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.

l2tp runs over UDP packets  (port 1701 (like the starship enterprise))
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
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to 
"freebsd-hackers-unsubscr...@freebsd.org"














___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"