Re: DLT Types

[Guy Harris <guy () alum mit edu>]

On Wednesday, July 2, 2003, at 12:20 AM, Muhammad Farooq-i-Azam wrote:

> 1- What are DLT_RAW and DLT_NULL? Please pardon my
> ignorance, but just when should I expect
> pcap_datalink() to return DLT_RAW or DLT_NULL.

Here's what the current CVS libpcap man page says:

                        DLT_NULL
                 BSD loopback encapsulation; the link layer header is a 
4-byte
                 field,  in  host  byte  order,  containing  a  PF_ 
value from
                 socket.h for the network-layer protocol of the packet

                 Note that ``host byte  order''  is  the  byte  order  
of  the
                 machine on which the packets are captured, and the PF_ 
values
                 are for the OS of the machine on which the packets  
are  cap-
                 tured;  if  a live capture is being done, ``host byte 
order''
                 is the byte order of the machine capturing the  
packets,  and
                 the  PF_  values are those of the OS of the machine 
capturing
                 the packets, but if a ``savefile'' is being  read,  
the  byte
                 order and PF_ values are not necessarily those of the 
machine
                 reading the capture file.

                                        ...

                        DLT_RAW
                 raw IP; the packet begins with an IP header


> (What is RAW IP

IP without any link-layer header before it.

>  and what kind of applications use it?)

Applications don't directly use *any* of the link-layer types; network 
devices, however, might.  Some network devices, when supplying packets 
to the OS's packet capture mechanism, supply only IP (v4 and possibly 
v6) packets, without any link-layer header.  The ones that apparently 
do so are:

	*some* PPP devices on Linux (although, in versions of libpcap built on 
systems with 2.2 or later kernels and running on systems with 2.2 or 
later kernels, DLT_LINUX_SLL is used instead, because one problem is 
that those devices don't necessarily supply only IP packets, which 
means DLT_RAW doesn't work);

        PPP devices on IRIX;

        possibly some devices on some BSDs.

> I believe they do not correspond to any physical
> entity/hardware on the network

Correct.  Not all DLT_ values directly correspond to physical link 
layers.

> and these are used as
> abstractions to facilitate something which I do  not
> know.

They're used to facilitate using libpcap-based applications on devices 
that don't supply to the packet capture mechanism used by libpcap a 
normal link-layer header.

> 2- When I try to capture packets from my loopback
> interface, pcap_datalink() returns DLT_EN10MB. Why?

Because whoever wrote the Linux network loopback device code decided to 
make it supply a fake Ethernet header.

> Then what is DLT_LOOP for?

OpenBSD loopback devices, which supply the header for DLT_LOOP:

                        DLT_LOOP
                 OpenBSD loopback encapsulation; the link layer  header 
 is  a
                 4-byte  field,  in network byte order, containing a 
PF_ value
                 from OpenBSD's socket.h for the network-layer protocol 
of the
                 packet

                 Note  that, if a ``savefile'' is being read, those PF_ 
values
                 are not necessarily those of the machine reading the  
capture
                 file.

> And what is more confusing,
> I read somewhere that getting DLT_NULL from
> pcap_datalink() will imply a loopback interface!!!

Yes.  The original BSD loopback device used DLT_NULL, which is just 
like DLT_LOOP except that the PF_ values are in the byte order of the 
host on which the capture is being done.

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe