Provided by: libpcap0.8-dev_1.1.1-10_amd64 bug

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                         PCAP-LINKTYPE(7)