at the end of the link-layer header; put it there.
Put in a comment indicating that the layout of the link-layer header
shouldn't be changed; if a new header is necessary, a new DLL_ type
should be introduced for it.
them in "print-sll.c" - as a cooked-mode capture may be reading from
non-Ethernet, non-802.x devices, it may well see some
ETH_P_/LINUX_SLL_P_ types that don't mean "this is an 802.2 LLC frame".
We currently assume that the ETH_P_ values won't change in the kernel,
so we don't have to explicitly map them.
we just treat the frame as an LLC frame (if we care about Novell
IPX-over-raw-802.3 frames, we'd have to handle them by checking for
0xFFFF as the first word - but we'd also have to do that when dissecting
Ethernet frames).
future Linux kernel changes the PACKET_ values out from under us, the
values recorded in the packet header in DLT_LINUX_SLL captures does
*not* change.
Don't map ETH_P_802_2 to the packet length, map it and ETH_P_802_3 to
standardized LINUX_SLL_P_ values, so that even if a future Linux kernel
changes the ETH_P_ values out from under us, the values recorded in the
packet header in DLT_LINUX_SLL captures does *not* change, and so that
you don't have to be running on Linux to be able to handle DLT_LINUX_SLL
captures.
live captures with a "cooked" (SOCK_DGRAM) rather than a "raw"
(SOCK_RAW) PF_PACKET socket; it includes a bunch of the fields from the
"struct sockaddr_ll" you get in a "recvfrom()", including the Ethernet
protocol field.
This requires us to rewrite the BPF program if we're stuffing it into
the kernel; as long as we're doing *ex post facto* rewriting, we might
as well also do the "ret <snaplen>" -> "ret 65535" fixup there as well,
rather than in the code generator.
itojun