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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
