1PCAP-LINKTYPE(7) Miscellaneous Information Manual PCAP-LINKTYPE(7)
2
6 pcap-linktype - link-layer header types supported by libpcap
7
9 For a live capture or ``savefile'', libpcap supplies, as the return
10 value of the pcap_datalink(3PCAP) routine, a value that indicates the
11 type of link-layer header at the beginning of the packets it provides.
12 This is not necessarily the type of link-layer header that the packets
13 being captured have on the network from which they're being captured;
14 for example, packets from an IEEE 802.11 network might be provided by
15 libpcap with Ethernet headers that the network adapter or the network
16 adapter driver generates from the 802.11 headers. The names for those
17 values begin with DLT_, so they are sometimes called "DLT_ values".
18 The values stored in the link-layer header type field in the savefile
20 header are, in most but not all cases, the same as the values returned
21 by pcap_datalink(). The names for those values begin with LINKTYPE_.
22 The link-layer header types supported by libpcap are listed here. The
24 value corresponding to LINKTYPE_ names are given; the value correspond‐
25 ing to DLT_ values are, in some cases, platform dependent, and are not
26 given; applications should check for particular DLT_ values by name.
27 DLT_NULL; LINKTYPE_NULL=0
29 BSD loopback encapsulation; the link-layer header is a 4-byte
30 field, in host byte order, containing a PF_ value from
31 socket.h for the network-layer protocol of the packet.
32 Note that ``host byte order'' is the byte order of the
34 machine on which the packets are captured, and the PF_ values
35 are for the OS of the machine on which the packets are cap‐
36 tured; if a live capture is being done, ``host byte order''
37 is the byte order of the machine capturing the packets, and
38 the PF_ values are those of the OS of the machine capturing
39 the packets, but if a ``savefile'' is being read, the byte
40 order and PF_ values are not necessarily those of the machine
41 reading the capture file.
42 DLT_EN10MB; LINKTYPE_ETHERNET=1
44 Ethernet (10Mb, 100Mb, 1000Mb, and up); the 10MB in the DLT_
45 name is historical.
46 DLT_IEEE802; LINKTYPE_TOKEN_RING=6
48 IEEE 802.5 Token Ring; the IEEE802 in the DLT_ name is his‐
49 torical.
50 DLT_ARCNET; LINKTYPE_ARCNET=7
52 ARCNET
53 DLT_SLIP; LINKTYPE_SLIP=8
55 SLIP; the link-layer header contains, in order:
56 a 1-byte flag, which is 0 for packets received by the
58 machine and 1 for packets sent by the machine;
59 a 1-byte field, the upper 4 bits of which indicate the
61 type of packet, as per RFC 1144:
62 0x40 an unmodified IP datagram (TYPE_IP);
64 0x70 an uncompressed-TCP IP datagram (UNCOM‐
66 PRESSED_TCP), with that byte being the first
67 byte of the raw IP header on the wire, con‐
68 taining the connection number in the protocol
69 field;
70 0x80 a compressed-TCP IP datagram (COMPRESSED_TCP),
72 with that byte being the first byte of the
73 compressed TCP/IP datagram header;
74 for UNCOMPRESSED_TCP, the rest of the modified IP
76 header, and for COMPRESSED_TCP, the compressed TCP/IP
77 datagram header;
78 for a total of 16 bytes; the uncompressed IP datagram follows
80 the header.
81 DLT_PPP; LINKTYPE_PPP=9
83 PPP; if the first 2 bytes are 0xff and 0x03, it's PPP in
84 HDLC-like framing, with the PPP header following those two
85 bytes, otherwise it's PPP without framing, and the packet
86 begins with the PPP header.
87 DLT_FDDI; LINKTYPE_FDDI=10
89 FDDI
90 DLT_ATM_RFC1483; LINKTYPE_ATM_RFC1483=100
92 RFC 1483 LLC/SNAP-encapsulated ATM; the packet begins with an
93 IEEE 802.2 LLC header.
94 DLT_RAW; LINKTYPE_RAW=101
96 raw IP; the packet begins with an IP header.
97 DLT_PPP_SERIAL; LINKTYPE_PPP_HDLC=50
99 PPP in HDLC-like framing, as per RFC 1662, or Cisco PPP with
100 HDLC framing, as per section 4.3.1 of RFC 1547; the first
101 byte will be 0xFF for PPP in HDLC-like framing, and will be
102 0x0F or 0x8F for Cisco PPP with HDLC framing.
103 DLT_PPP_ETHER; LINKTYPE_PPP_ETHER=51
105 PPPoE; the packet begins with a PPPoE header, as per RFC
106 2516.
107 DLT_C_HDLC; LINKTYPE_C_HDLC=104
109 Cisco PPP with HDLC framing, as per section 4.3.1 of RFC
110 1547.
111 DLT_IEEE802_11; LINKTYPE_IEEE802_11=105
113 IEEE 802.11 wireless LAN
114 DLT_FRELAY; LINKTYPE_FRELAY=107
116 Frame Relay
117 DLT_LOOP; LINKTYPE_LOOP=108
119 OpenBSD loopback encapsulation; the link-layer header is a
120 4-byte field, in network byte order, containing a PF_ value
121 from OpenBSD's socket.h for the network-layer protocol of the
122 packet.
123 Note that, if a ``savefile'' is being read, those PF_ values
125 are not necessarily those of the machine reading the capture
126 file.
127 DLT_LINUX_SLL; LINKTYPE_LINUX_SLL=113
129 Linux "cooked" capture encapsulation; the link-layer header
130 contains, in order:
131 a 2-byte "packet type", in network byte order, which is
133 one of:
134 0 packet was sent to us by somebody else
136 1 packet was broadcast by somebody else
138 2 packet was multicast, but not broadcast, by
140 somebody else
141 3 packet was sent by somebody else to somebody
143 else
144 4 packet was sent by us
146 a 2-byte field, in network byte order, containing a
148 Linux ARPHRD_ value for the link-layer device type;
149 a 2-byte field, in network byte order, containing the
151 length of the link-layer address of the sender of the
152 packet (which could be 0);
153 an 8-byte field containing that number of bytes of the
155 link-layer address of the sender (if there are more than
156 8 bytes, only the first 8 are present, and if there are
157 fewer than 8 bytes, there are padding bytes after the
158 address to pad the field to 8 bytes);
159 a 2-byte field containing an Ethernet protocol type, in
161 network byte order, or containing 1 for Novell 802.3
162 frames without an 802.2 LLC header or 4 for frames
163 beginning with an 802.2 LLC header.
164 DLT_LTALK; LINKTYPE_LTALK=104
166 Apple LocalTalk; the packet begins with an AppleTalk LLAP
167 header.
168 DLT_PFLOG; LINKTYPE_PFLOG=117
170 OpenBSD pflog; the link-layer header contains a struct
171 pfloghdr structure, as defined by the host on which the file
172 was saved. (This differs from operating system to operating
173 system and release to release; there is nothing in the file
174 to indicate what the layout of that structure is.)
175 DLT_PRISM_HEADER; LINKTYPE_PRISM_HEADER=119
177 Prism monitor mode information followed by an 802.11 header.
178 DLT_IP_OVER_FC; LINKTYPE_IP_OVER_FC=122
180 RFC 2625 IP-over-Fibre Channel, with the link-layer header
181 being the Network_Header as described in that RFC.
182 DLT_SUNATM; LINKTYPE_SUNATM=123
184 SunATM devices; the link-layer header contains, in order:
185 a 1-byte flag field, containing a direction flag in the
187 uppermost bit, which is set for packets transmitted by
188 the machine and clear for packets received by the
189 machine, and a 4-byte traffic type in the low-order 4
190 bits, which is one of:
191 0 raw traffic
193 1 LANE traffic
195 2 LLC-encapsulated traffic
197 3 MARS traffic
199 4 IFMP traffic
201 5 ILMI traffic
203 6 Q.2931 traffic
205 a 1-byte VPI value;
207 a 2-byte VCI field, in network byte order.
209 DLT_IEEE802_11_RADIO; LINKTYPE_IEEE802_11_RADIO=127
211 link-layer information followed by an 802.11 header - see
212 http://www.shaftnet.org/~pizza/software/capturefrm.txt for a
213 description of the link-layer information.
214 DLT_ARCNET_LINUX; LINKTYPE_ARCNET_LINUX=129
216 ARCNET, with no exception frames, reassembled packets rather
217 than raw frames, and an extra 16-bit offset field between the
218 destination host and type bytes.
219 DLT_LINUX_IRDA; LINKTYPE_LINUX_IRDA=144
221 Linux-IrDA packets, with a DLT_LINUX_SLL header followed by
222 the IrLAP header.
223 DLT_LINUX_LAPD; LINKTYPE_LINUX_LAPD=177
225 LAPD (Q.921) frames, with a DLT_LINUX_SLL header captured via
226 vISDN.
227
229 pcap_datalink(3PCAP)
230 23 October 2008 PCAP-LINKTYPE(7)