Ethereal-users: RE: [Ethereal-users] OT: How does ethereal/libpcap determine the layer 3 type?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "darren" <teodarren@xxxxxxxxxxxxx>
Date: Wed, 3 Sep 2003 22:02:18 +0800
Hi Guy,

Thanx once again for the ever insightful reply!

I can understand that libpcap inserts the LCS header in front if it gets a
new ARP type that does not match its list...just wondering which command is
it exactly that libpcap use to fetch the L3 protocol type from the kernel
network stack?

Any reason why my card driver strips the L2 header away when I specify the
encapsulation type?

Also...do you know of any HSSI and DS3 cards that would return the whole L2
header (either CHDLC or FR or PPP) and still works with the PF_PACKET
structure?

Rgds
darren
-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx] 
Sent: Wednesday, September 03, 2003 12:39 PM
To: darren
Cc: ethereal-users@xxxxxxxxxxxx
Subject: Re: [Ethereal-users] OT: How does ethereal/libpcap determine the
layer 3 type?

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).