Date: Wed, 08 Jun 2005 08:56:35 +1200 From: Matthew Luckie <mjl@luckie.org.nz> To: Charles Swiger <cswiger@mac.com> Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device Message-ID: <42A60A03.2000101@luckie.org.nz> In-Reply-To: <43393A5D-A13B-4385-A6E3-EDD21343277A@mac.com> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> <20050607112340.GC812@empiric.icir.org> <42A5FB72.4010603@luckie.org.nz> <43393A5D-A13B-4385-A6E3-EDD21343277A@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> this was the behaviour expected of most DLT_NULL bpf devices already >> (passing a 32bit int when writing). It is important to note that the >> behaviour of BPF writers does not change in these cases, and my patch >> is merely a bug fix. > > Agreed. When you use BPF or PCAP to capture packets, for the DTL_NULL > case there is a 4-byte offset between where PCAP says the packet starts > and where the actual raw IP packet starts. > > If you want BPF/PCAP to return packets without the 4-byte offset, the > associated datalink type is actually called DLT_RAW. Note that the > behavior of DLT_NULL is useful in practice, since you can find out what > the "ether type" of the packet was per <net/ethernet.h>: unless i'm mistaken, the 4 byte field is actually the address family of the packet. so AF_INET, AF_INET6, etc. the ethertype thing is for DLT_EN10MB devices. Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42A60A03.2000101>