Date: Tue, 7 Jun 2005 17:36:02 -0400 From: Charles Swiger <cswiger@mac.com> To: Matthew Luckie <mjl@luckie.org.nz> Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device Message-ID: <6C52F579-B9E9-43DF-A169-561209DA010B@mac.com> In-Reply-To: <42A60A03.2000101@luckie.org.nz> 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> <42A60A03.2000101@luckie.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 7, 2005, at 4:56 PM, Matthew Luckie wrote: >> 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. If you're trying to write traffic using socket(), sure, you might very well specify AF_INET as the first argument (domain), but the machine doesn't actually put the value of the address family into the link-level header of the packet that goes out across the wire. I agree that the ethertype thing is supposed to be for ethernet-style devices, but try sending some traffic over lo0, and capture it, and take a look at the first four bytes. Maybe I'm confused, but I remember seeing 0x0800 and 0x86dd, respectively, not 0x2 (AF_INET) or 30 (AF_INET6). When writing packets, I found that even using SOCK_RAW the kernel would fill in a lot of stuff that I didn't want it to, and instead I needed to talk with BPF directly or use something like libnet to build the packets. I am pretty sure this is why the ISC DHCP software depends on BPF, because it can't generate ARPOP_REQUESTS and so forth using the normal socket mechanisms to query whether an IP addr is in use...? -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C52F579-B9E9-43DF-A169-561209DA010B>