pcap-linktype(7)
- NetBSD Manual Pages
PCAP-LINKTYPE(7) PCAP-LINKTYPE(7)
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(3) 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 libp-
cap 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 correspond-
ing 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 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_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 his-
torical.
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 (UNCOM-
PRESSED_TCP), with that byte being the first
byte of the raw IP header on the wire, con-
taining 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(3)
23 October 2008 PCAP-LINKTYPE(7)
Powered by man-cgi (2024-03-20).
Maintained for NetBSD
by Kimmo Suominen.
Based on man-cgi by Panagiotis Christias.