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-08-26). Maintained for NetBSD by Kimmo Suominen. Based on man-cgi by Panagiotis Christias.