bpf writes on tun device

[Charles Swiger]

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