On Wed, Sep 03, 2003 at 03:45:37AM +0000, darren wrote:
> I am wondering how the libpcap engine determine the type of layer 3
> (issit IP or IPX...blah blah) protocol during a capture.
The libpcap code doesn't do that itself. The BPF program it, or the BPF
interpreter in kernel mode, is interpreting would do so if it needed to
look at the layer 3 header or headers above that.
> I was doing a capture with a WAN card that will stripe away the L2
> header.
>
> so...ethereal reported a "ARP type unknown" and replaced the L2 with a
> Linux Cooked Socket instead.
Libpcap does that, on Linux, if it sees an ARPHRD_ value it doesn't know
about.
What was the numerical value reported for the ARP type, if any? Either
we should try to map it to an existing DLT_ value, create a new DLT_
value for it, or have it silently map that ARPHRD_ value to
DLT_LINUX_COOKED.
> The miraculous thing is that it actually
> identified the L3 protocol type correctly as IP (0x0800) in the Linux
> Cooked socket header even though the original L2 header is no longer
> avbl.
Presumably either
1) the card doesn't strip away the L2 header, the driver does -
if so, then the driver *has* to supply the L3 protocol type to
the Linux networking stack, otherwise it wouldn't be able to
handle the packet at all, and, in a "Linux cooked mode"
capture, libpcap gets the L3 protocol type from the Linux
networking stack
or
2) the card strips away the L2 header but supplies the L3
protocol type to the driver (it has to, as per the comment in
item 1).
