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