from small one page howto to huge articles all in one place
poll results
Last additions:
May 25th. 2007:
April, 26th. 2006:
| You are here: manpages
PCAP-LINKTYPE
Section: Environments, Tables, and Troff Macros (7) Updated: 23 October 2008 Index
Return to Main Contents
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)
Index
- NAME
-
- DESCRIPTION
-
- SEE ALSO
-
Please read "Why adblockers are badwww.cars2fast4u.de
|
Other free services .
.
|