NAME
pcap-linktype - link-layer header types supported by libpcap
DESCRIPTION
For a live capture or ‘‘savefile’’, libpcap supplies, as the return
value of the pcap_datalink(3PCAP) routine, a value that indicates the
type of link-layer header at the beginning of the packets it provides.
This is not necessarily the type of link-layer header that the packets
being captured have on the network from which they’re being captured;
for example, packets from an IEEE 802.11 network might be provided by
libpcap with Ethernet headers that the network adapter or the network
adapter driver generates from the 802.11 headers. The names for those
values begin with DLT_, so they are sometimes called "DLT_ values".
The values stored in the link-layer header type field in the savefile
header are, in most but not all cases, the same as the values returned
by pcap_datalink(). The names for those values begin with LINKTYPE_.
The link-layer header types supported by libpcap are listed here. The
value corresponding to LINKTYPE_ names are given; the value
corresponding to DLT_ values are, in some cases, platform dependent,
and are not given; applications should check for particular DLT_ values
by name.
DLT_NULL; LINKTYPE_NULL=0
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
captured; 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_EN10MB; LINKTYPE_ETHERNET=1
Ethernet (10Mb, 100Mb, 1000Mb, and up); the 10MB in the DLT_
name is historical.
DLT_IEEE802; LINKTYPE_TOKEN_RING=6
IEEE 802.5 Token Ring; the IEEE802 in the DLT_ name is
historical.
DLT_ARCNET; LINKTYPE_ARCNET=7
ARCNET
DLT_SLIP; LINKTYPE_SLIP=8
SLIP; the link-layer header contains, in order:
a 1-byte flag, which is 0 for packets received by the
machine and 1 for packets sent by the machine;
a 1-byte field, the upper 4 bits of which indicate the
type of packet, as per RFC 1144:
0x40 an unmodified IP datagram (TYPE_IP);
0x70 an uncompressed-TCP IP datagram
(UNCOMPRESSED_TCP), with that byte being the
first byte of the raw IP header on the wire,
containing the connection number in the
protocol field;
0x80 a compressed-TCP IP datagram (COMPRESSED_TCP),
with that byte being the first byte of the
compressed TCP/IP datagram header;
for UNCOMPRESSED_TCP, the rest of the modified IP
header, and for COMPRESSED_TCP, the compressed TCP/IP
datagram header;
for a total of 16 bytes; the uncompressed IP datagram follows
the header.
DLT_PPP; LINKTYPE_PPP=9
PPP; if the first 2 bytes are 0xff and 0x03, it’s PPP in
HDLC-like framing, with the PPP header following those two
bytes, otherwise it’s PPP without framing, and the packet
begins with the PPP header.
DLT_FDDI; LINKTYPE_FDDI=10
FDDI
DLT_ATM_RFC1483; LINKTYPE_ATM_RFC1483=100
RFC 1483 LLC/SNAP-encapsulated ATM; the packet begins with an
IEEE 802.2 LLC header.
DLT_RAW; LINKTYPE_RAW=101
raw IP; the packet begins with an IP header.
DLT_PPP_SERIAL; LINKTYPE_PPP_HDLC=50
PPP in HDLC-like framing, as per RFC 1662, or Cisco PPP with
HDLC framing, as per section 4.3.1 of RFC 1547; the first
byte will be 0xFF for PPP in HDLC-like framing, and will be
0x0F or 0x8F for Cisco PPP with HDLC framing.
DLT_PPP_ETHER; LINKTYPE_PPP_ETHER=51
PPPoE; the packet begins with a PPPoE header, as per RFC
2516.
DLT_C_HDLC; LINKTYPE_C_HDLC=104
Cisco PPP with HDLC framing, as per section 4.3.1 of RFC
1547.
DLT_IEEE802_11; LINKTYPE_IEEE802_11=105
IEEE 802.11 wireless LAN
DLT_FRELAY; LINKTYPE_FRELAY=107
Frame Relay
DLT_LOOP; LINKTYPE_LOOP=108
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.
DLT_LINUX_SLL; LINKTYPE_LINUX_SLL=113
Linux "cooked" capture encapsulation; the link-layer header
contains, in order:
a 2-byte "packet type", in network byte order, which is
one of:
0 packet was sent to us by somebody else
1 packet was broadcast by somebody else
2 packet was multicast, but not broadcast, by
somebody else
3 packet was sent by somebody else to somebody
else
4 packet was sent by us
a 2-byte field, in network byte order, containing a
Linux ARPHRD_ value for the link-layer device type;
a 2-byte field, in network byte order, containing the
length of the link-layer address of the sender of the
packet (which could be 0);
an 8-byte field containing that number of bytes of the
link-layer address of the sender (if there are more than
8 bytes, only the first 8 are present, and if there are
fewer than 8 bytes, there are padding bytes after the
address to pad the field to 8 bytes);
a 2-byte field containing an Ethernet protocol type, in
network byte order, or containing 1 for Novell 802.3
frames without an 802.2 LLC header or 4 for frames
beginning with an 802.2 LLC header.
DLT_LTALK; LINKTYPE_LTALK=104
Apple LocalTalk; the packet begins with an AppleTalk LLAP
header.
DLT_PFLOG; LINKTYPE_PFLOG=117
OpenBSD pflog; the link-layer header contains a struct
pfloghdr structure, as defined by the host on which the file
was saved. (This differs from operating system to operating
system and release to release; there is nothing in the file
to indicate what the layout of that structure is.)
DLT_PRISM_HEADER; LINKTYPE_PRISM_HEADER=119
Prism monitor mode information followed by an 802.11 header.
DLT_IP_OVER_FC; LINKTYPE_IP_OVER_FC=122
RFC 2625 IP-over-Fibre Channel, with the link-layer header
being the Network_Header as described in that RFC.
DLT_SUNATM; LINKTYPE_SUNATM=123
SunATM devices; the link-layer header contains, in order:
a 1-byte flag field, containing a direction flag in the
uppermost bit, which is set for packets transmitted by
the machine and clear for packets received by the
machine, and a 4-byte traffic type in the low-order 4
bits, which is one of:
0 raw traffic
1 LANE traffic
2 LLC-encapsulated traffic
3 MARS traffic
4 IFMP traffic
5 ILMI traffic
6 Q.2931 traffic
a 1-byte VPI value;
a 2-byte VCI field, in network byte order.
DLT_IEEE802_11_RADIO; LINKTYPE_IEEE802_11_RADIO=127
link-layer information followed by an 802.11 header - see
http://www.shaftnet.org/~pizza/software/capturefrm.txt for a
description of the link-layer information.
DLT_ARCNET_LINUX; LINKTYPE_ARCNET_LINUX=129
ARCNET, with no exception frames, reassembled packets rather
than raw frames, and an extra 16-bit offset field between the
destination host and type bytes.
DLT_LINUX_IRDA; LINKTYPE_LINUX_IRDA=144
Linux-IrDA packets, with a DLT_LINUX_SLL header followed by
the IrLAP header.
DLT_LINUX_LAPD; LINKTYPE_LINUX_LAPD=177
LAPD (Q.921) frames, with a DLT_LINUX_SLL header captured via
vISDN.
SEE ALSO
pcap_datalink(3PCAP)
23 October 2008