[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' 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 at freebsd.org mailing list
>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>>>>> To unsubscribe, send any mail to 
>>>>>> "freebsd-hackers-unsubscribe at freebsd.org"
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>