forked from osmocom/wireshark
Have the libpcap and pcap-NG code share the LINKTYPE_-to-WTAP_ENCAP_
mapping table - they should be using the same values. Share the mapping routines as well. svn path=/trunk/; revision=28173
This commit is contained in:
parent
2b36f00d1c
commit
18a3b0659c
|
@ -62,6 +62,7 @@ NONGENERATED_C_FILES = \
|
|||
netxray.c \
|
||||
ngsniffer.c \
|
||||
packetlogger.c \
|
||||
pcap-common.c \
|
||||
pcapng.c \
|
||||
pppdump.c \
|
||||
radcom.c \
|
||||
|
@ -108,6 +109,7 @@ NONGENERATED_HEADER_FILES = \
|
|||
netxray.h \
|
||||
ngsniffer.h \
|
||||
packetlogger.h \
|
||||
pcap-common.h \
|
||||
pcapng.h \
|
||||
pppdump.h \
|
||||
radcom.h \
|
||||
|
|
|
@ -32,6 +32,7 @@
|
|||
#include "buffer.h"
|
||||
#include "atm.h"
|
||||
#include "erf.h"
|
||||
#include "pcap-common.h"
|
||||
#include "libpcap.h"
|
||||
|
||||
/*
|
||||
|
@ -177,530 +178,6 @@ static void libpcap_close(wtap *wth);
|
|||
static gboolean libpcap_dump(wtap_dumper *wdh, const struct wtap_pkthdr *phdr,
|
||||
const union wtap_pseudo_header *pseudo_header, const guchar *pd, int *err);
|
||||
|
||||
/*
|
||||
* Either LBL NRG wasn't an adequate central registry (e.g., because of
|
||||
* the slow rate of releases from them), or nobody bothered using them
|
||||
* as a central registry, as many different groups have patched libpcap
|
||||
* (and BPF, on the BSDs) to add new encapsulation types, and have ended
|
||||
* up using the same DLT_ values for different encapsulation types.
|
||||
*
|
||||
* For those numerical encapsulation type values that everybody uses for
|
||||
* the same encapsulation type (which inclues those that some platforms
|
||||
* specify different DLT_ names for but don't appear to use), we map
|
||||
* those values to the appropriate Wiretap values.
|
||||
*
|
||||
* For those numerical encapsulation type values that different libpcap
|
||||
* variants use for different encapsulation types, we check what
|
||||
* <pcap.h> defined to determine how to interpret them, so that we
|
||||
* interpret them the way the libpcap with which we're building
|
||||
* Wireshark/Wiretap interprets them (which, if it doesn't support
|
||||
* them at all, means we don't support them either - any capture files
|
||||
* using them are foreign, and we don't hazard a guess as to which
|
||||
* platform they came from; we could, I guess, choose the most likely
|
||||
* platform).
|
||||
*
|
||||
* Note: if you need a new encapsulation type for libpcap files, do
|
||||
* *N*O*T* use *ANY* of the values listed here! I.e., do *NOT*
|
||||
* add a new encapsulation type by changing an existing entry;
|
||||
* leave the existing entries alone.
|
||||
*
|
||||
* Instead, send mail to tcpdump-workers@lists.tcpdump.org, asking for
|
||||
* a new DLT_ value, and specifying the purpose of the new value. When
|
||||
* you get the new DLT_ value, use that numerical value in the "dlt_value"
|
||||
* field of "pcap_to_wtap_map[]".
|
||||
*/
|
||||
|
||||
static const struct {
|
||||
int dlt_value;
|
||||
int wtap_encap_value;
|
||||
} pcap_to_wtap_map[] = {
|
||||
/*
|
||||
* These are the values that are almost certainly the same
|
||||
* in all libpcaps (I've yet to find one where the values
|
||||
* in question are used for some purpose other than the
|
||||
* one below, but...), and that Wiretap and Wireshark
|
||||
* currently support.
|
||||
*/
|
||||
{ 0, WTAP_ENCAP_NULL }, /* null encapsulation */
|
||||
{ 1, WTAP_ENCAP_ETHERNET },
|
||||
{ 6, WTAP_ENCAP_TOKEN_RING }, /* IEEE 802 Networks - assume token ring */
|
||||
{ 7, WTAP_ENCAP_ARCNET },
|
||||
{ 8, WTAP_ENCAP_SLIP },
|
||||
{ 9, WTAP_ENCAP_PPP },
|
||||
#ifdef BIT_SWAPPED_MAC_ADDRS
|
||||
{ 10, WTAP_ENCAP_FDDI_BITSWAPPED },
|
||||
#else
|
||||
{ 10, WTAP_ENCAP_FDDI },
|
||||
#endif
|
||||
|
||||
{ 32, WTAP_ENCAP_REDBACK },
|
||||
|
||||
/*
|
||||
* 50 is DLT_PPP_SERIAL in NetBSD; it appears that DLT_PPP
|
||||
* on BSD (at least according to standard tcpdump) has, as
|
||||
* the first octet, an indication of whether the packet was
|
||||
* transmitted or received (rather than having the standard
|
||||
* PPP address value of 0xff), but that DLT_PPP_SERIAL puts
|
||||
* a real live PPP header there, or perhaps a Cisco PPP header
|
||||
* as per section 4.3.1 of RFC 1547 (implementations of this
|
||||
* exist in various BSDs in "sys/net/if_spppsubr.c", and
|
||||
* I think also exist either in standard Linux or in
|
||||
* various Linux patches; the implementations show how to handle
|
||||
* Cisco keepalive packets).
|
||||
*
|
||||
* However, I don't see any obvious place in FreeBSD "if_ppp.c"
|
||||
* where anything other than the standard PPP header would be
|
||||
* passed up. I see some stuff that sets the first octet
|
||||
* to 0 for incoming and 1 for outgoing packets before applying
|
||||
* a BPF filter to see whether to drop packets whose protocol
|
||||
* field has the 0x8000 bit set, i.e. network control protocols -
|
||||
* those are handed up to userland - but that code puts the
|
||||
* address field back before passing the packet up.
|
||||
*
|
||||
* I also don't see anything immediately obvious that munges
|
||||
* the address field for sync PPP, either.
|
||||
*
|
||||
* Wireshark currently assumes that if the first octet of a
|
||||
* PPP frame is 0xFF, it's the address field and is followed
|
||||
* by a control field and a 2-byte protocol, otherwise the
|
||||
* address and control fields are absent and the frame begins
|
||||
* with a protocol field. If we ever see a BSD/OS PPP
|
||||
* capture, we'll have to handle it differently, and we may
|
||||
* have to handle standard BSD captures differently if, in fact,
|
||||
* they don't have 0xff 0x03 as the first two bytes - but, as per
|
||||
* the two paragraphs preceding this, it's not clear that
|
||||
* the address field *is* munged into an incoming/outgoing
|
||||
* field when the packet is handed to the BPF device.
|
||||
*
|
||||
* For now, we just map DLT_PPP_SERIAL to WTAP_ENCAP_PPP, as
|
||||
* we treat WTAP_ENCAP_PPP packets as if those beginning with
|
||||
* 0xff have the standard RFC 1662 "PPP in HDLC-like Framing"
|
||||
* 0xff 0x03 address/control header, and DLT_PPP_SERIAL frames
|
||||
* appear to contain that unless they're Cisco frames (if we
|
||||
* ever see a capture with them, we'd need to implement the
|
||||
* RFC 1547 stuff, and the keepalive protocol stuff).
|
||||
*
|
||||
* We may have to distinguish between "PPP where if it doesn't
|
||||
* begin with 0xff there's no HDLC encapsulation and the frame
|
||||
* begins with the protocol field" (which is how we handle
|
||||
* WTAP_ENCAP_PPP now) and "PPP where there's either HDLC
|
||||
* encapsulation or Cisco PPP" (which is what DLT_PPP_SERIAL
|
||||
* is) at some point.
|
||||
*
|
||||
* XXX - NetBSD has DLT_HDLC, which appears to be used for
|
||||
* Cisco HDLC. Ideally, they should use DLT_PPP_SERIAL
|
||||
* only for real live HDLC-encapsulated PPP, not for Cisco
|
||||
* HDLC.
|
||||
*/
|
||||
{ 50, WTAP_ENCAP_PPP },
|
||||
|
||||
/*
|
||||
* Apparently used by the Axent Raptor firewall (now Symantec
|
||||
* Enterprise Firewall).
|
||||
* Thanks, Axent, for not reserving that type with tcpdump.org
|
||||
* and not telling anybody about it.
|
||||
*/
|
||||
{ 99, WTAP_ENCAP_SYMANTEC },
|
||||
|
||||
/*
|
||||
* These are the values that libpcap 0.5 and later use in
|
||||
* capture file headers, in an attempt to work around the
|
||||
* confusion decried above, and that Wiretap and Wireshark
|
||||
* currently support.
|
||||
*/
|
||||
{ 100, WTAP_ENCAP_ATM_RFC1483 },
|
||||
{ 101, WTAP_ENCAP_RAW_IP },
|
||||
#if 0
|
||||
/*
|
||||
* More values used by libpcap 0.5 as DLT_ values and used by the
|
||||
* current CVS version of libpcap in capture file headers.
|
||||
* They are not yet handled in Wireshark.
|
||||
* If we get a capture that contains them, we'll implement them.
|
||||
*/
|
||||
{ 102, WTAP_ENCAP_SLIP_BSDOS },
|
||||
{ 103, WTAP_ENCAP_PPP_BSDOS },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* These ones are handled in Wireshark, though.
|
||||
*/
|
||||
{ 104, WTAP_ENCAP_CHDLC }, /* Cisco HDLC */
|
||||
{ 105, WTAP_ENCAP_IEEE_802_11 }, /* IEEE 802.11 */
|
||||
{ 106, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
{ 107, WTAP_ENCAP_FRELAY }, /* Frame Relay */
|
||||
{ 108, WTAP_ENCAP_NULL }, /* OpenBSD loopback */
|
||||
{ 109, WTAP_ENCAP_ENC }, /* OpenBSD IPSEC enc */
|
||||
#if 0
|
||||
{ 110, WTAP_ENCAP_LANE_802_3 },/* ATM LANE 802.3 */
|
||||
{ 111, WTAP_ENCAP_HIPPI }, /* NetBSD HIPPI */
|
||||
#endif
|
||||
{ 112, WTAP_ENCAP_CHDLC }, /* NetBSD HDLC framing */
|
||||
|
||||
/*
|
||||
* Linux "cooked mode" captures, used by the current CVS version
|
||||
* of libpcap
|
||||
* OR
|
||||
* it could be a packet in Cisco's ERSPAN encapsulation which uses
|
||||
* this number as well (why can't people stick to protocols when it
|
||||
* comes to allocating/using DLT types).
|
||||
*/
|
||||
{ 113, WTAP_ENCAP_SLL }, /* Linux cooked capture */
|
||||
|
||||
{ 114, WTAP_ENCAP_LOCALTALK }, /* Localtalk */
|
||||
|
||||
/*
|
||||
* The tcpdump.org version of libpcap uses 117, rather than 17,
|
||||
* for OpenBSD packet filter logging, so as to avoid conflicting
|
||||
* with DLT_LANE8023 in SuSE 6.3 libpcap.
|
||||
*/
|
||||
{ 117, WTAP_ENCAP_PFLOG },
|
||||
|
||||
{ 118, WTAP_ENCAP_CISCO_IOS },
|
||||
{ 119, WTAP_ENCAP_PRISM_HEADER }, /* Prism monitor mode hdr */
|
||||
{ 121, WTAP_ENCAP_HHDLC }, /* HiPath HDLC */
|
||||
{ 122, WTAP_ENCAP_IP_OVER_FC }, /* RFC 2625 IP-over-FC */
|
||||
{ 123, WTAP_ENCAP_ATM_PDUS }, /* SunATM */
|
||||
{ 127, WTAP_ENCAP_IEEE_802_11_WLAN_RADIOTAP }, /* 802.11 plus radiotap WLAN header */
|
||||
{ 128, WTAP_ENCAP_TZSP }, /* Tazmen Sniffer Protocol */
|
||||
{ 129, WTAP_ENCAP_ARCNET_LINUX },
|
||||
{ 130, WTAP_ENCAP_JUNIPER_MLPPP }, /* Juniper MLPPP on ML-, LS-, AS- PICs */
|
||||
{ 131, WTAP_ENCAP_JUNIPER_MLFR }, /* Juniper MLFR (FRF.15) on ML-, LS-, AS- PICs */
|
||||
{ 133, WTAP_ENCAP_JUNIPER_GGSN},
|
||||
/*
|
||||
* Values 132-134, 136 not listed here are reserved for use
|
||||
* in Juniper hardware.
|
||||
*/
|
||||
{ 135, WTAP_ENCAP_JUNIPER_ATM2 }, /* various encapsulations captured on the ATM2 PIC */
|
||||
{ 137, WTAP_ENCAP_JUNIPER_ATM1 }, /* various encapsulations captured on the ATM1 PIC */
|
||||
|
||||
{ 138, WTAP_ENCAP_APPLE_IP_OVER_IEEE1394 },
|
||||
/* Apple IP-over-IEEE 1394 */
|
||||
|
||||
{ 139, WTAP_ENCAP_MTP2_WITH_PHDR },
|
||||
{ 140, WTAP_ENCAP_MTP2 },
|
||||
{ 141, WTAP_ENCAP_MTP3 },
|
||||
{ 142, WTAP_ENCAP_SCCP },
|
||||
{ 143, WTAP_ENCAP_DOCSIS },
|
||||
{ 144, WTAP_ENCAP_IRDA }, /* IrDA capture */
|
||||
|
||||
/* Reserved for private use. */
|
||||
{ 147, WTAP_ENCAP_USER0 },
|
||||
{ 148, WTAP_ENCAP_USER1 },
|
||||
{ 149, WTAP_ENCAP_USER2 },
|
||||
{ 150, WTAP_ENCAP_USER3 },
|
||||
{ 151, WTAP_ENCAP_USER4 },
|
||||
{ 152, WTAP_ENCAP_USER5 },
|
||||
{ 153, WTAP_ENCAP_USER6 },
|
||||
{ 154, WTAP_ENCAP_USER7 },
|
||||
{ 155, WTAP_ENCAP_USER8 },
|
||||
{ 156, WTAP_ENCAP_USER9 },
|
||||
{ 157, WTAP_ENCAP_USER10 },
|
||||
{ 158, WTAP_ENCAP_USER11 },
|
||||
{ 159, WTAP_ENCAP_USER12 },
|
||||
{ 160, WTAP_ENCAP_USER13 },
|
||||
{ 161, WTAP_ENCAP_USER14 },
|
||||
{ 162, WTAP_ENCAP_USER15 },
|
||||
|
||||
{ 163, WTAP_ENCAP_IEEE_802_11_WLAN_AVS }, /* 802.11 plus AVS WLAN header */
|
||||
|
||||
/*
|
||||
* 164 is reserved for Juniper-private chassis-internal
|
||||
* meta-information such as QoS profiles, etc..
|
||||
*/
|
||||
|
||||
{ 165, WTAP_ENCAP_BACNET_MS_TP },
|
||||
|
||||
/*
|
||||
* 166 is reserved for a PPP variant in which the first byte
|
||||
* of the 0xff03 header, the 0xff, is replaced by a direction
|
||||
* byte. I don't know whether any captures look like that,
|
||||
* but it is used for some Linux IP filtering (ipfilter?).
|
||||
*/
|
||||
|
||||
/* Ethernet PPPoE frames captured on a service PIC */
|
||||
{ 167, WTAP_ENCAP_JUNIPER_PPPOE },
|
||||
|
||||
/*
|
||||
* 168 is reserved for more Juniper private-chassis-
|
||||
* internal meta-information.
|
||||
*/
|
||||
|
||||
{ 169, WTAP_ENCAP_GPRS_LLC },
|
||||
|
||||
/*
|
||||
* 170 and 171 are reserved for ITU-T G.7041/Y.1303 Generic
|
||||
* Framing Procedure.
|
||||
*/
|
||||
|
||||
/* Registered by Gcom, Inc. */
|
||||
{ 172, WTAP_GCOM_TIE1 },
|
||||
{ 173, WTAP_GCOM_SERIAL },
|
||||
|
||||
{ 177, WTAP_ENCAP_LINUX_LAPD },
|
||||
|
||||
/* Ethernet frames prepended with meta-information */
|
||||
{ 178, WTAP_ENCAP_JUNIPER_ETHER },
|
||||
/* PPP frames prepended with meta-information */
|
||||
{ 179, WTAP_ENCAP_JUNIPER_PPP },
|
||||
/* Frame-Relay frames prepended with meta-information */
|
||||
{ 180, WTAP_ENCAP_JUNIPER_FRELAY },
|
||||
/* C-HDLC frames prepended with meta-information */
|
||||
{ 181, WTAP_ENCAP_JUNIPER_CHDLC },
|
||||
/* VOIP Frames prepended with meta-information */
|
||||
{ 183, WTAP_ENCAP_JUNIPER_VP },
|
||||
/* raw USB packets */
|
||||
{ 186, WTAP_ENCAP_USB },
|
||||
/* Bluetooth HCI UART transport (part H:4) frames, like hcidump */
|
||||
{ 187, WTAP_ENCAP_BLUETOOTH_H4 },
|
||||
/* IEEE 802.16 MAC Common Part Sublayer */
|
||||
{ 188, WTAP_ENCAP_IEEE802_16_MAC_CPS },
|
||||
/* USB packets with Linux-specified header */
|
||||
{ 189, WTAP_ENCAP_USB_LINUX },
|
||||
/* CAN 2.0b frame */
|
||||
{ 190, WTAP_ENCAP_CAN20B },
|
||||
/* Per-Packet Information header */
|
||||
{ 192, WTAP_ENCAP_PPI },
|
||||
/* IEEE 802.15.4 Wireless PAN */
|
||||
{ 195, WTAP_ENCAP_IEEE802_15_4 },
|
||||
/* SITA File Encapsulation */
|
||||
{ 196, WTAP_ENCAP_SITA },
|
||||
/* Endace Record File Encapsulation */
|
||||
{ 197, WTAP_ENCAP_ERF },
|
||||
/* IPMB */
|
||||
{ 199, WTAP_ENCAP_IPMB },
|
||||
/* Bluetooth HCI UART transport (part H:4) frames, like hcidump */
|
||||
{ 201, WTAP_ENCAP_BLUETOOTH_H4_WITH_PHDR },
|
||||
/* IPMB/I2C */
|
||||
{ 209, WTAP_ENCAP_I2C },
|
||||
/* FlexRay frame */
|
||||
{ 210, WTAP_ENCAP_FLEXRAY },
|
||||
/* MOST frame */
|
||||
{ 211, WTAP_ENCAP_MOST },
|
||||
/* LIN frame */
|
||||
{ 212, WTAP_ENCAP_LIN },
|
||||
/* X2E Xoraya serial frame */
|
||||
{ 213, WTAP_ENCAP_X2E_SERIAL },
|
||||
/* X2E Xoraya frame */
|
||||
{ 214, WTAP_ENCAP_X2E_XORAYA },
|
||||
/* IEEE 802.15.4 Wireless PAN non-ASK PHY */
|
||||
{ 215, WTAP_ENCAP_IEEE802_15_4_NONASK_PHY },
|
||||
/* USB packets with padded Linux-specified header */
|
||||
{ 220, WTAP_ENCAP_USB_LINUX_MMAPPED },
|
||||
|
||||
/*
|
||||
* To repeat:
|
||||
*
|
||||
* If you need a new encapsulation type for libpcap files, do
|
||||
* *N*O*T* use *ANY* of the values listed here! I.e., do *NOT*
|
||||
* add a new encapsulation type by changing an existing entry;
|
||||
* leave the existing entries alone.
|
||||
*
|
||||
* Instead, send mail to tcpdump-workers@lists.tcpdump.org, asking
|
||||
* for a new DLT_ value, and specifying the purpose of the new value.
|
||||
* When you get the new DLT_ value, use that numerical value in
|
||||
* the "dlt_value" field of "pcap_to_wtap_map[]".
|
||||
*/
|
||||
|
||||
/*
|
||||
* The following are entries for libpcap type values that have
|
||||
* different meanings on different OSes.
|
||||
*
|
||||
* We put these *after* the entries for the platform-independent
|
||||
* libpcap type values for those Wiretap encapsulation types, so
|
||||
* that Wireshark chooses the platform-independent libpcap type
|
||||
* value for those encapsulatioin types, not the platform-dependent
|
||||
* one.
|
||||
*/
|
||||
|
||||
/*
|
||||
* 11 is DLT_ATM_RFC1483 on most platforms; the only libpcaps I've
|
||||
* seen that define anything other than DLT_ATM_RFC1483 as 11 are
|
||||
* the BSD/OS one, which defines DLT_FR as 11, and libpcap 0.5,
|
||||
* which define it as 100, mapping the kernel's value to 100, in
|
||||
* an attempt to hide the different values used on different
|
||||
* platforms.
|
||||
*
|
||||
* If this is a platform where DLT_FR is defined as 11, we
|
||||
* don't handle 11 at all; otherwise, we handle it as
|
||||
* DLT_ATM_RFC1483 (this means we'd misinterpret Frame Relay
|
||||
* captures from BSD/OS if running on platforms other than BSD/OS,
|
||||
* but
|
||||
*
|
||||
* 1) we don't yet support DLT_FR
|
||||
*
|
||||
* and
|
||||
*
|
||||
* 2) nothing short of a heuristic would let us interpret
|
||||
* them correctly).
|
||||
*/
|
||||
#if defined(DLT_FR) && (DLT_FR == 11)
|
||||
{ 11, WTAP_ENCAP_FRELAY },
|
||||
#else
|
||||
{ 11, WTAP_ENCAP_ATM_RFC1483 },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 12 is DLT_RAW on most platforms, but it's DLT_C_HDLC on
|
||||
* BSD/OS, and DLT_LOOP on OpenBSD.
|
||||
*
|
||||
* We don't yet handle DLT_C_HDLC, but we can handle DLT_LOOP
|
||||
* (it's just like DLT_NULL, only with the AF_ value in network
|
||||
* rather than host byte order - Wireshark figures out the
|
||||
* byte order from the data, so we don't care what byte order
|
||||
* it's in), so if DLT_LOOP is defined as 12, interpret 12
|
||||
* as WTAP_ENCAP_NULL, otherwise, unless DLT_C_HDLC is defined
|
||||
* as 12, interpret it as WTAP_ENCAP_RAW_IP.
|
||||
*/
|
||||
#if defined(DLT_LOOP) && (DLT_LOOP == 12)
|
||||
{ 12, WTAP_ENCAP_NULL },
|
||||
#elif defined(DLT_C_HDLC) && (DLT_C_HDLC == 12)
|
||||
/*
|
||||
* Put entry for Cisco HDLC here.
|
||||
* XXX - is this just WTAP_ENCAP_CHDLC, i.e. does the frame
|
||||
* start with a 4-byte Cisco HDLC header?
|
||||
*/
|
||||
#else
|
||||
{ 12, WTAP_ENCAP_RAW_IP },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 13 is DLT_SLIP_BSDOS on FreeBSD and NetBSD, but those OSes
|
||||
* don't actually generate it. I infer that BSD/OS translates
|
||||
* DLT_SLIP from the kernel BPF code to DLT_SLIP_BSDOS in
|
||||
* libpcap, as the BSD/OS link-layer header is different;
|
||||
* however, in BSD/OS, DLT_SLIP_BSDOS is 15.
|
||||
*
|
||||
* From this, I infer that there's no point in handling 13
|
||||
* as DLT_SLIP_BSDOS.
|
||||
*
|
||||
* 13 is DLT_ATM_RFC1483 on BSD/OS.
|
||||
*
|
||||
* 13 is DLT_ENC in OpenBSD, which is, I suspect, some kind
|
||||
* of decrypted IPSEC traffic.
|
||||
*/
|
||||
#if defined(DLT_ATM_RFC1483) && (DLT_ATM_RFC1483 == 13)
|
||||
{ 13, WTAP_ENCAP_ATM_RFC1483 },
|
||||
#elif defined(DLT_ENC) && (DLT_ENC == 13)
|
||||
{ 13, WTAP_ENCAP_ENC },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 14 is DLT_PPP_BSDOS on FreeBSD and NetBSD, but those OSes
|
||||
* don't actually generate it. I infer that BSD/OS translates
|
||||
* DLT_PPP from the kernel BPF code to DLT_PPP_BSDOS in
|
||||
* libpcap, as the BSD/OS link-layer header is different;
|
||||
* however, in BSD/OS, DLT_PPP_BSDOS is 16.
|
||||
*
|
||||
* From this, I infer that there's no point in handling 14
|
||||
* as DLT_PPP_BSDOS.
|
||||
*
|
||||
* 14 is DLT_RAW on BSD/OS and OpenBSD.
|
||||
*/
|
||||
{ 14, WTAP_ENCAP_RAW_IP },
|
||||
|
||||
/*
|
||||
* 15 is:
|
||||
*
|
||||
* DLT_SLIP_BSDOS on BSD/OS;
|
||||
*
|
||||
* DLT_HIPPI on NetBSD;
|
||||
*
|
||||
* DLT_LANE8023 with Alexey Kuznetzov's patches for
|
||||
* Linux libpcap;
|
||||
*
|
||||
* DLT_I4L_RAWIP with the ISDN4Linux patches for libpcap
|
||||
* (and on SuSE 6.3);
|
||||
*
|
||||
* but we don't currently handle any of those.
|
||||
*/
|
||||
|
||||
/*
|
||||
* 16 is:
|
||||
*
|
||||
* DLT_PPP_BSDOS on BSD/OS;
|
||||
*
|
||||
* DLT_HDLC on NetBSD (Cisco HDLC);
|
||||
*
|
||||
* DLT_CIP with Alexey Kuznetzov's patches for
|
||||
* Linux libpcap - this is WTAP_ENCAP_LINUX_ATM_CLIP;
|
||||
*
|
||||
* DLT_I4L_IP with the ISDN4Linux patches for libpcap
|
||||
* (and on SuSE 6.3).
|
||||
*/
|
||||
#if defined(DLT_CIP) && (DLT_CIP == 16)
|
||||
{ 16, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
#endif
|
||||
#if defined(DLT_HDLC) && (DLT_HDLC == 16)
|
||||
{ 16, WTAP_ENCAP_CHDLC },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 17 is DLT_LANE8023 in SuSE 6.3 libpcap; we don't currently
|
||||
* handle it.
|
||||
* It is also used as the PF (Packet Filter) logging format beginning
|
||||
* with OpenBSD 3.0; we use 17 for PF logs unless DLT_LANE8023 is
|
||||
* defined with the value 17.
|
||||
*/
|
||||
#if !defined(DLT_LANE8023) || (DLT_LANE8023 != 17)
|
||||
{ 17, WTAP_ENCAP_OLD_PFLOG },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 18 is DLT_CIP in SuSE 6.3 libpcap; if it's the same as the
|
||||
* DLT_CIP of 16 that the Alexey Kuznetzov patches for
|
||||
* libpcap/tcpdump define, it's WTAP_ENCAP_LINUX_ATM_CLIP.
|
||||
* I've not found any libpcap that uses it for any other purpose -
|
||||
* hopefully nobody will do so in the future.
|
||||
*/
|
||||
{ 18, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
|
||||
/*
|
||||
* 19 is DLT_ATM_CLIP in the libpcap/tcpdump patches in the
|
||||
* recent versions I've seen of the Linux ATM distribution;
|
||||
* I've not yet found any libpcap that uses it for any other
|
||||
* purpose - hopefully nobody will do so in the future.
|
||||
*/
|
||||
{ 19, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
|
||||
/*
|
||||
* nettl (HP-UX) mappings to standard DLT values
|
||||
*/
|
||||
|
||||
{ 1, WTAP_ENCAP_NETTL_ETHERNET },
|
||||
{ 6, WTAP_ENCAP_NETTL_TOKEN_RING },
|
||||
{ 10, WTAP_ENCAP_NETTL_FDDI },
|
||||
{ 70, WTAP_ENCAP_RAW_IP },
|
||||
{ 101, WTAP_ENCAP_NETTL_RAW_IP },
|
||||
|
||||
/*
|
||||
* To repeat:
|
||||
*
|
||||
* If you need a new encapsulation type for libpcap files, do
|
||||
* *N*O*T* use *ANY* of the values listed here! I.e., do *NOT*
|
||||
* add a new encapsulation type by changing an existing entry;
|
||||
* leave the existing entries alone.
|
||||
*
|
||||
* Instead, send mail to tcpdump-workers@lists.tcpdump.org, asking
|
||||
* for a new DLT_ value, and specifying the purpose of the new value.
|
||||
* When you get the new DLT_ value, use that numerical value in
|
||||
* the "dlt_value" field of "pcap_to_wtap_map[]".
|
||||
*/
|
||||
|
||||
};
|
||||
#define NUM_PCAP_ENCAPS (sizeof pcap_to_wtap_map / sizeof pcap_to_wtap_map[0])
|
||||
|
||||
int wtap_pcap_encap_to_wtap_encap(int encap)
|
||||
{
|
||||
unsigned int i;
|
||||
|
||||
for (i = 0; i < NUM_PCAP_ENCAPS; i++) {
|
||||
if (pcap_to_wtap_map[i].dlt_value == encap)
|
||||
return pcap_to_wtap_map[i].wtap_encap_value;
|
||||
}
|
||||
return WTAP_ENCAP_UNKNOWN;
|
||||
}
|
||||
|
||||
|
||||
int libpcap_open(wtap *wth, int *err, gchar **err_info)
|
||||
{
|
||||
int bytes_read;
|
||||
|
@ -2431,69 +1908,6 @@ libpcap_close(wtap *wth)
|
|||
g_free(wth->capture.pcap);
|
||||
}
|
||||
|
||||
static int wtap_wtap_encap_to_pcap_encap(int encap)
|
||||
{
|
||||
unsigned int i;
|
||||
|
||||
switch (encap) {
|
||||
|
||||
case WTAP_ENCAP_FDDI:
|
||||
case WTAP_ENCAP_FDDI_BITSWAPPED:
|
||||
case WTAP_ENCAP_NETTL_FDDI:
|
||||
/*
|
||||
* Special-case WTAP_ENCAP_FDDI and
|
||||
* WTAP_ENCAP_FDDI_BITSWAPPED; both of them get mapped
|
||||
* to DLT_FDDI (even though that may mean that the bit
|
||||
* order in the FDDI MAC addresses is wrong; so it goes
|
||||
* - libpcap format doesn't record the byte order,
|
||||
* so that's not fixable).
|
||||
*/
|
||||
return 10; /* that's DLT_FDDI */
|
||||
|
||||
case WTAP_ENCAP_PPP_WITH_PHDR:
|
||||
/*
|
||||
* Also special-case PPP with direction bits; map it to
|
||||
* PPP, even though that means that the direction of the
|
||||
* packet is lost.
|
||||
*/
|
||||
return 9;
|
||||
|
||||
case WTAP_ENCAP_FRELAY_WITH_PHDR:
|
||||
/*
|
||||
* Do the same with Frame Relay.
|
||||
*/
|
||||
return 107;
|
||||
|
||||
case WTAP_ENCAP_IEEE_802_11_WITH_RADIO:
|
||||
/*
|
||||
* Map this to DLT_IEEE802_11, for now, even though
|
||||
* that means the radio information will be lost.
|
||||
* Once tcpdump support for the BSD radiotap header
|
||||
* is sufficiently widespread, we should probably
|
||||
* use that, instead - although we should probably
|
||||
* ultimately just have WTAP_ENCAP_IEEE_802_11
|
||||
* as the only Wiretap encapsulation for 802.11,
|
||||
* and have the pseudo-header include a radiotap-style
|
||||
* list of attributes. If we do that, though, we
|
||||
* should probably bypass the regular Wiretap code
|
||||
* when writing out packets during a capture, and just
|
||||
* do the equivalent of a libpcap write (unfortunately,
|
||||
* libpcap doesn't have an "open dump by file descriptor"
|
||||
* function, so we can't just use "pcap_dump()"), so
|
||||
* that we don't spend cycles mapping from libpcap to
|
||||
* Wiretap and then back to libpcap. (There are other
|
||||
* reasons to do that, e.g. to handle AIX libpcap better.)
|
||||
*/
|
||||
return 105;
|
||||
}
|
||||
|
||||
for (i = 0; i < NUM_PCAP_ENCAPS; i++) {
|
||||
if (pcap_to_wtap_map[i].wtap_encap_value == encap)
|
||||
return pcap_to_wtap_map[i].dlt_value;
|
||||
}
|
||||
return -1;
|
||||
}
|
||||
|
||||
/* Returns 0 if we could write the specified encapsulation type,
|
||||
an error indication otherwise. */
|
||||
int libpcap_dump_can_write_encap(int encap)
|
||||
|
|
|
@ -0,0 +1,615 @@
|
|||
/* pcap-common.c
|
||||
* Code common to libpcap and pcap-NG file formats
|
||||
*
|
||||
* $Id$
|
||||
*
|
||||
* Wiretap Library
|
||||
* Copyright (c) 1998 by Gilbert Ramirez <gram@alumni.rice.edu>
|
||||
*
|
||||
* File format support for pcap-ng file format
|
||||
* Copyright (c) 2007 by Ulf Lamping <ulf.lamping@web.de>
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU General Public License
|
||||
* as published by the Free Software Foundation; either version 2
|
||||
* of the License, or (at your option) any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
*/
|
||||
|
||||
#include "wtap.h"
|
||||
#include "pcap-common.h"
|
||||
|
||||
/*
|
||||
* Map link-layer types (LINKTYPE_ values) to Wiretap encapsulations.
|
||||
*/
|
||||
/*
|
||||
* Either LBL NRG wasn't an adequate central registry (e.g., because of
|
||||
* the slow rate of releases from them), or nobody bothered using them
|
||||
* as a central registry, as many different groups have patched libpcap
|
||||
* (and BPF, on the BSDs) to add new encapsulation types, and have ended
|
||||
* up using the same DLT_ values for different encapsulation types.
|
||||
*
|
||||
* For those numerical encapsulation type values that everybody uses for
|
||||
* the same encapsulation type (which inclues those that some platforms
|
||||
* specify different DLT_ names for but don't appear to use), we map
|
||||
* those values to the appropriate Wiretap values.
|
||||
*
|
||||
* For those numerical encapsulation type values that different libpcap
|
||||
* variants use for different encapsulation types, we check what
|
||||
* <pcap.h> defined to determine how to interpret them, so that we
|
||||
* interpret them the way the libpcap with which we're building
|
||||
* Wireshark/Wiretap interprets them (which, if it doesn't support
|
||||
* them at all, means we don't support them either - any capture files
|
||||
* using them are foreign, and we don't hazard a guess as to which
|
||||
* platform they came from; we could, I guess, choose the most likely
|
||||
* platform).
|
||||
*
|
||||
* Note: if you need a new encapsulation type for libpcap files, do
|
||||
* *N*O*T* use *ANY* of the values listed here! I.e., do *NOT*
|
||||
* add a new encapsulation type by changing an existing entry;
|
||||
* leave the existing entries alone.
|
||||
*
|
||||
* Instead, send mail to tcpdump-workers@lists.tcpdump.org, asking for
|
||||
* a new DLT_ value, and specifying the purpose of the new value. When
|
||||
* you get the new DLT_ value, use that numerical value in the "dlt_value"
|
||||
* field of "pcap_to_wtap_map[]".
|
||||
*/
|
||||
|
||||
const struct encap_map pcap_to_wtap_map[] = {
|
||||
/*
|
||||
* These are the values that are almost certainly the same
|
||||
* in all libpcaps (I've yet to find one where the values
|
||||
* in question are used for some purpose other than the
|
||||
* one below, but...), and that Wiretap and Wireshark
|
||||
* currently support.
|
||||
*/
|
||||
{ 0, WTAP_ENCAP_NULL }, /* null encapsulation */
|
||||
{ 1, WTAP_ENCAP_ETHERNET },
|
||||
{ 6, WTAP_ENCAP_TOKEN_RING }, /* IEEE 802 Networks - assume token ring */
|
||||
{ 7, WTAP_ENCAP_ARCNET },
|
||||
{ 8, WTAP_ENCAP_SLIP },
|
||||
{ 9, WTAP_ENCAP_PPP },
|
||||
#ifdef BIT_SWAPPED_MAC_ADDRS
|
||||
{ 10, WTAP_ENCAP_FDDI_BITSWAPPED },
|
||||
#else
|
||||
{ 10, WTAP_ENCAP_FDDI },
|
||||
#endif
|
||||
|
||||
{ 32, WTAP_ENCAP_REDBACK },
|
||||
|
||||
/*
|
||||
* 50 is DLT_PPP_SERIAL in NetBSD; it appears that DLT_PPP
|
||||
* on BSD (at least according to standard tcpdump) has, as
|
||||
* the first octet, an indication of whether the packet was
|
||||
* transmitted or received (rather than having the standard
|
||||
* PPP address value of 0xff), but that DLT_PPP_SERIAL puts
|
||||
* a real live PPP header there, or perhaps a Cisco PPP header
|
||||
* as per section 4.3.1 of RFC 1547 (implementations of this
|
||||
* exist in various BSDs in "sys/net/if_spppsubr.c", and
|
||||
* I think also exist either in standard Linux or in
|
||||
* various Linux patches; the implementations show how to handle
|
||||
* Cisco keepalive packets).
|
||||
*
|
||||
* However, I don't see any obvious place in FreeBSD "if_ppp.c"
|
||||
* where anything other than the standard PPP header would be
|
||||
* passed up. I see some stuff that sets the first octet
|
||||
* to 0 for incoming and 1 for outgoing packets before applying
|
||||
* a BPF filter to see whether to drop packets whose protocol
|
||||
* field has the 0x8000 bit set, i.e. network control protocols -
|
||||
* those are handed up to userland - but that code puts the
|
||||
* address field back before passing the packet up.
|
||||
*
|
||||
* I also don't see anything immediately obvious that munges
|
||||
* the address field for sync PPP, either.
|
||||
*
|
||||
* Wireshark currently assumes that if the first octet of a
|
||||
* PPP frame is 0xFF, it's the address field and is followed
|
||||
* by a control field and a 2-byte protocol, otherwise the
|
||||
* address and control fields are absent and the frame begins
|
||||
* with a protocol field. If we ever see a BSD/OS PPP
|
||||
* capture, we'll have to handle it differently, and we may
|
||||
* have to handle standard BSD captures differently if, in fact,
|
||||
* they don't have 0xff 0x03 as the first two bytes - but, as per
|
||||
* the two paragraphs preceding this, it's not clear that
|
||||
* the address field *is* munged into an incoming/outgoing
|
||||
* field when the packet is handed to the BPF device.
|
||||
*
|
||||
* For now, we just map DLT_PPP_SERIAL to WTAP_ENCAP_PPP, as
|
||||
* we treat WTAP_ENCAP_PPP packets as if those beginning with
|
||||
* 0xff have the standard RFC 1662 "PPP in HDLC-like Framing"
|
||||
* 0xff 0x03 address/control header, and DLT_PPP_SERIAL frames
|
||||
* appear to contain that unless they're Cisco frames (if we
|
||||
* ever see a capture with them, we'd need to implement the
|
||||
* RFC 1547 stuff, and the keepalive protocol stuff).
|
||||
*
|
||||
* We may have to distinguish between "PPP where if it doesn't
|
||||
* begin with 0xff there's no HDLC encapsulation and the frame
|
||||
* begins with the protocol field" (which is how we handle
|
||||
* WTAP_ENCAP_PPP now) and "PPP where there's either HDLC
|
||||
* encapsulation or Cisco PPP" (which is what DLT_PPP_SERIAL
|
||||
* is) at some point.
|
||||
*
|
||||
* XXX - NetBSD has DLT_HDLC, which appears to be used for
|
||||
* Cisco HDLC. Ideally, they should use DLT_PPP_SERIAL
|
||||
* only for real live HDLC-encapsulated PPP, not for Cisco
|
||||
* HDLC.
|
||||
*/
|
||||
{ 50, WTAP_ENCAP_PPP },
|
||||
|
||||
/*
|
||||
* Apparently used by the Axent Raptor firewall (now Symantec
|
||||
* Enterprise Firewall).
|
||||
* Thanks, Axent, for not reserving that type with tcpdump.org
|
||||
* and not telling anybody about it.
|
||||
*/
|
||||
{ 99, WTAP_ENCAP_SYMANTEC },
|
||||
|
||||
/*
|
||||
* These are the values that libpcap 0.5 and later use in
|
||||
* capture file headers, in an attempt to work around the
|
||||
* confusion decried above, and that Wiretap and Wireshark
|
||||
* currently support.
|
||||
*/
|
||||
{ 100, WTAP_ENCAP_ATM_RFC1483 },
|
||||
{ 101, WTAP_ENCAP_RAW_IP },
|
||||
#if 0
|
||||
/*
|
||||
* More values used by libpcap 0.5 as DLT_ values and used by the
|
||||
* current CVS version of libpcap in capture file headers.
|
||||
* They are not yet handled in Wireshark.
|
||||
* If we get a capture that contains them, we'll implement them.
|
||||
*/
|
||||
{ 102, WTAP_ENCAP_SLIP_BSDOS },
|
||||
{ 103, WTAP_ENCAP_PPP_BSDOS },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* These ones are handled in Wireshark, though.
|
||||
*/
|
||||
{ 104, WTAP_ENCAP_CHDLC }, /* Cisco HDLC */
|
||||
{ 105, WTAP_ENCAP_IEEE_802_11 }, /* IEEE 802.11 */
|
||||
{ 106, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
{ 107, WTAP_ENCAP_FRELAY }, /* Frame Relay */
|
||||
{ 108, WTAP_ENCAP_NULL }, /* OpenBSD loopback */
|
||||
{ 109, WTAP_ENCAP_ENC }, /* OpenBSD IPSEC enc */
|
||||
#if 0
|
||||
{ 110, WTAP_ENCAP_LANE_802_3 },/* ATM LANE 802.3 */
|
||||
{ 111, WTAP_ENCAP_HIPPI }, /* NetBSD HIPPI */
|
||||
#endif
|
||||
{ 112, WTAP_ENCAP_CHDLC }, /* NetBSD HDLC framing */
|
||||
|
||||
/*
|
||||
* Linux "cooked mode" captures, used by the current CVS version
|
||||
* of libpcap
|
||||
* OR
|
||||
* it could be a packet in Cisco's ERSPAN encapsulation which uses
|
||||
* this number as well (why can't people stick to protocols when it
|
||||
* comes to allocating/using DLT types).
|
||||
*/
|
||||
{ 113, WTAP_ENCAP_SLL }, /* Linux cooked capture */
|
||||
|
||||
{ 114, WTAP_ENCAP_LOCALTALK }, /* Localtalk */
|
||||
|
||||
/*
|
||||
* The tcpdump.org version of libpcap uses 117, rather than 17,
|
||||
* for OpenBSD packet filter logging, so as to avoid conflicting
|
||||
* with DLT_LANE8023 in SuSE 6.3 libpcap.
|
||||
*/
|
||||
{ 117, WTAP_ENCAP_PFLOG },
|
||||
|
||||
{ 118, WTAP_ENCAP_CISCO_IOS },
|
||||
{ 119, WTAP_ENCAP_PRISM_HEADER }, /* Prism monitor mode hdr */
|
||||
{ 121, WTAP_ENCAP_HHDLC }, /* HiPath HDLC */
|
||||
{ 122, WTAP_ENCAP_IP_OVER_FC }, /* RFC 2625 IP-over-FC */
|
||||
{ 123, WTAP_ENCAP_ATM_PDUS }, /* SunATM */
|
||||
{ 127, WTAP_ENCAP_IEEE_802_11_WLAN_RADIOTAP }, /* 802.11 plus radiotap WLAN header */
|
||||
{ 128, WTAP_ENCAP_TZSP }, /* Tazmen Sniffer Protocol */
|
||||
{ 129, WTAP_ENCAP_ARCNET_LINUX },
|
||||
{ 130, WTAP_ENCAP_JUNIPER_MLPPP }, /* Juniper MLPPP on ML-, LS-, AS- PICs */
|
||||
{ 131, WTAP_ENCAP_JUNIPER_MLFR }, /* Juniper MLFR (FRF.15) on ML-, LS-, AS- PICs */
|
||||
{ 133, WTAP_ENCAP_JUNIPER_GGSN},
|
||||
/*
|
||||
* Values 132-134, 136 not listed here are reserved for use
|
||||
* in Juniper hardware.
|
||||
*/
|
||||
{ 135, WTAP_ENCAP_JUNIPER_ATM2 }, /* various encapsulations captured on the ATM2 PIC */
|
||||
{ 137, WTAP_ENCAP_JUNIPER_ATM1 }, /* various encapsulations captured on the ATM1 PIC */
|
||||
|
||||
{ 138, WTAP_ENCAP_APPLE_IP_OVER_IEEE1394 },
|
||||
/* Apple IP-over-IEEE 1394 */
|
||||
|
||||
{ 139, WTAP_ENCAP_MTP2_WITH_PHDR },
|
||||
{ 140, WTAP_ENCAP_MTP2 },
|
||||
{ 141, WTAP_ENCAP_MTP3 },
|
||||
{ 142, WTAP_ENCAP_SCCP },
|
||||
{ 143, WTAP_ENCAP_DOCSIS },
|
||||
{ 144, WTAP_ENCAP_IRDA }, /* IrDA capture */
|
||||
|
||||
/* Reserved for private use. */
|
||||
{ 147, WTAP_ENCAP_USER0 },
|
||||
{ 148, WTAP_ENCAP_USER1 },
|
||||
{ 149, WTAP_ENCAP_USER2 },
|
||||
{ 150, WTAP_ENCAP_USER3 },
|
||||
{ 151, WTAP_ENCAP_USER4 },
|
||||
{ 152, WTAP_ENCAP_USER5 },
|
||||
{ 153, WTAP_ENCAP_USER6 },
|
||||
{ 154, WTAP_ENCAP_USER7 },
|
||||
{ 155, WTAP_ENCAP_USER8 },
|
||||
{ 156, WTAP_ENCAP_USER9 },
|
||||
{ 157, WTAP_ENCAP_USER10 },
|
||||
{ 158, WTAP_ENCAP_USER11 },
|
||||
{ 159, WTAP_ENCAP_USER12 },
|
||||
{ 160, WTAP_ENCAP_USER13 },
|
||||
{ 161, WTAP_ENCAP_USER14 },
|
||||
{ 162, WTAP_ENCAP_USER15 },
|
||||
|
||||
{ 163, WTAP_ENCAP_IEEE_802_11_WLAN_AVS }, /* 802.11 plus AVS WLAN header */
|
||||
|
||||
/*
|
||||
* 164 is reserved for Juniper-private chassis-internal
|
||||
* meta-information such as QoS profiles, etc..
|
||||
*/
|
||||
|
||||
{ 165, WTAP_ENCAP_BACNET_MS_TP },
|
||||
|
||||
/*
|
||||
* 166 is reserved for a PPP variant in which the first byte
|
||||
* of the 0xff03 header, the 0xff, is replaced by a direction
|
||||
* byte. I don't know whether any captures look like that,
|
||||
* but it is used for some Linux IP filtering (ipfilter?).
|
||||
*/
|
||||
|
||||
/* Ethernet PPPoE frames captured on a service PIC */
|
||||
{ 167, WTAP_ENCAP_JUNIPER_PPPOE },
|
||||
|
||||
/*
|
||||
* 168 is reserved for more Juniper private-chassis-
|
||||
* internal meta-information.
|
||||
*/
|
||||
|
||||
{ 169, WTAP_ENCAP_GPRS_LLC },
|
||||
|
||||
/*
|
||||
* 170 and 171 are reserved for ITU-T G.7041/Y.1303 Generic
|
||||
* Framing Procedure.
|
||||
*/
|
||||
|
||||
/* Registered by Gcom, Inc. */
|
||||
{ 172, WTAP_GCOM_TIE1 },
|
||||
{ 173, WTAP_GCOM_SERIAL },
|
||||
|
||||
{ 177, WTAP_ENCAP_LINUX_LAPD },
|
||||
|
||||
/* Ethernet frames prepended with meta-information */
|
||||
{ 178, WTAP_ENCAP_JUNIPER_ETHER },
|
||||
/* PPP frames prepended with meta-information */
|
||||
{ 179, WTAP_ENCAP_JUNIPER_PPP },
|
||||
/* Frame-Relay frames prepended with meta-information */
|
||||
{ 180, WTAP_ENCAP_JUNIPER_FRELAY },
|
||||
/* C-HDLC frames prepended with meta-information */
|
||||
{ 181, WTAP_ENCAP_JUNIPER_CHDLC },
|
||||
/* VOIP Frames prepended with meta-information */
|
||||
{ 183, WTAP_ENCAP_JUNIPER_VP },
|
||||
/* raw USB packets */
|
||||
{ 186, WTAP_ENCAP_USB },
|
||||
/* Bluetooth HCI UART transport (part H:4) frames, like hcidump */
|
||||
{ 187, WTAP_ENCAP_BLUETOOTH_H4 },
|
||||
/* IEEE 802.16 MAC Common Part Sublayer */
|
||||
{ 188, WTAP_ENCAP_IEEE802_16_MAC_CPS },
|
||||
/* USB packets with Linux-specified header */
|
||||
{ 189, WTAP_ENCAP_USB_LINUX },
|
||||
/* CAN 2.0b frame */
|
||||
{ 190, WTAP_ENCAP_CAN20B },
|
||||
/* Per-Packet Information header */
|
||||
{ 192, WTAP_ENCAP_PPI },
|
||||
/* IEEE 802.15.4 Wireless PAN */
|
||||
{ 195, WTAP_ENCAP_IEEE802_15_4 },
|
||||
/* SITA File Encapsulation */
|
||||
{ 196, WTAP_ENCAP_SITA },
|
||||
/* Endace Record File Encapsulation */
|
||||
{ 197, WTAP_ENCAP_ERF },
|
||||
/* IPMB */
|
||||
{ 199, WTAP_ENCAP_IPMB },
|
||||
/* Bluetooth HCI UART transport (part H:4) frames, like hcidump */
|
||||
{ 201, WTAP_ENCAP_BLUETOOTH_H4_WITH_PHDR },
|
||||
/* IPMB/I2C */
|
||||
{ 209, WTAP_ENCAP_I2C },
|
||||
/* FlexRay frame */
|
||||
{ 210, WTAP_ENCAP_FLEXRAY },
|
||||
/* MOST frame */
|
||||
{ 211, WTAP_ENCAP_MOST },
|
||||
/* LIN frame */
|
||||
{ 212, WTAP_ENCAP_LIN },
|
||||
/* X2E Xoraya serial frame */
|
||||
{ 213, WTAP_ENCAP_X2E_SERIAL },
|
||||
/* X2E Xoraya frame */
|
||||
{ 214, WTAP_ENCAP_X2E_XORAYA },
|
||||
/* IEEE 802.15.4 Wireless PAN non-ASK PHY */
|
||||
{ 215, WTAP_ENCAP_IEEE802_15_4_NONASK_PHY },
|
||||
/* USB packets with padded Linux-specified header */
|
||||
{ 220, WTAP_ENCAP_USB_LINUX_MMAPPED },
|
||||
|
||||
/*
|
||||
* To repeat:
|
||||
*
|
||||
* If you need a new encapsulation type for libpcap files, do
|
||||
* *N*O*T* use *ANY* of the values listed here! I.e., do *NOT*
|
||||
* add a new encapsulation type by changing an existing entry;
|
||||
* leave the existing entries alone.
|
||||
*
|
||||
* Instead, send mail to tcpdump-workers@lists.tcpdump.org, asking
|
||||
* for a new DLT_ value, and specifying the purpose of the new value.
|
||||
* When you get the new DLT_ value, use that numerical value in
|
||||
* the "dlt_value" field of "pcap_to_wtap_map[]".
|
||||
*/
|
||||
|
||||
/*
|
||||
* The following are entries for libpcap type values that have
|
||||
* different meanings on different OSes.
|
||||
*
|
||||
* We put these *after* the entries for the platform-independent
|
||||
* libpcap type values for those Wiretap encapsulation types, so
|
||||
* that Wireshark chooses the platform-independent libpcap type
|
||||
* value for those encapsulatioin types, not the platform-dependent
|
||||
* one.
|
||||
*/
|
||||
|
||||
/*
|
||||
* 11 is DLT_ATM_RFC1483 on most platforms; the only libpcaps I've
|
||||
* seen that define anything other than DLT_ATM_RFC1483 as 11 are
|
||||
* the BSD/OS one, which defines DLT_FR as 11, and libpcap 0.5,
|
||||
* which define it as 100, mapping the kernel's value to 100, in
|
||||
* an attempt to hide the different values used on different
|
||||
* platforms.
|
||||
*
|
||||
* If this is a platform where DLT_FR is defined as 11, we
|
||||
* don't handle 11 at all; otherwise, we handle it as
|
||||
* DLT_ATM_RFC1483 (this means we'd misinterpret Frame Relay
|
||||
* captures from BSD/OS if running on platforms other than BSD/OS,
|
||||
* but
|
||||
*
|
||||
* 1) we don't yet support DLT_FR
|
||||
*
|
||||
* and
|
||||
*
|
||||
* 2) nothing short of a heuristic would let us interpret
|
||||
* them correctly).
|
||||
*/
|
||||
#if defined(DLT_FR) && (DLT_FR == 11)
|
||||
{ 11, WTAP_ENCAP_FRELAY },
|
||||
#else
|
||||
{ 11, WTAP_ENCAP_ATM_RFC1483 },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 12 is DLT_RAW on most platforms, but it's DLT_C_HDLC on
|
||||
* BSD/OS, and DLT_LOOP on OpenBSD.
|
||||
*
|
||||
* We don't yet handle DLT_C_HDLC, but we can handle DLT_LOOP
|
||||
* (it's just like DLT_NULL, only with the AF_ value in network
|
||||
* rather than host byte order - Wireshark figures out the
|
||||
* byte order from the data, so we don't care what byte order
|
||||
* it's in), so if DLT_LOOP is defined as 12, interpret 12
|
||||
* as WTAP_ENCAP_NULL, otherwise, unless DLT_C_HDLC is defined
|
||||
* as 12, interpret it as WTAP_ENCAP_RAW_IP.
|
||||
*/
|
||||
#if defined(DLT_LOOP) && (DLT_LOOP == 12)
|
||||
{ 12, WTAP_ENCAP_NULL },
|
||||
#elif defined(DLT_C_HDLC) && (DLT_C_HDLC == 12)
|
||||
/*
|
||||
* Put entry for Cisco HDLC here.
|
||||
* XXX - is this just WTAP_ENCAP_CHDLC, i.e. does the frame
|
||||
* start with a 4-byte Cisco HDLC header?
|
||||
*/
|
||||
#else
|
||||
{ 12, WTAP_ENCAP_RAW_IP },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 13 is DLT_SLIP_BSDOS on FreeBSD and NetBSD, but those OSes
|
||||
* don't actually generate it. I infer that BSD/OS translates
|
||||
* DLT_SLIP from the kernel BPF code to DLT_SLIP_BSDOS in
|
||||
* libpcap, as the BSD/OS link-layer header is different;
|
||||
* however, in BSD/OS, DLT_SLIP_BSDOS is 15.
|
||||
*
|
||||
* From this, I infer that there's no point in handling 13
|
||||
* as DLT_SLIP_BSDOS.
|
||||
*
|
||||
* 13 is DLT_ATM_RFC1483 on BSD/OS.
|
||||
*
|
||||
* 13 is DLT_ENC in OpenBSD, which is, I suspect, some kind
|
||||
* of decrypted IPSEC traffic.
|
||||
*/
|
||||
#if defined(DLT_ATM_RFC1483) && (DLT_ATM_RFC1483 == 13)
|
||||
{ 13, WTAP_ENCAP_ATM_RFC1483 },
|
||||
#elif defined(DLT_ENC) && (DLT_ENC == 13)
|
||||
{ 13, WTAP_ENCAP_ENC },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 14 is DLT_PPP_BSDOS on FreeBSD and NetBSD, but those OSes
|
||||
* don't actually generate it. I infer that BSD/OS translates
|
||||
* DLT_PPP from the kernel BPF code to DLT_PPP_BSDOS in
|
||||
* libpcap, as the BSD/OS link-layer header is different;
|
||||
* however, in BSD/OS, DLT_PPP_BSDOS is 16.
|
||||
*
|
||||
* From this, I infer that there's no point in handling 14
|
||||
* as DLT_PPP_BSDOS.
|
||||
*
|
||||
* 14 is DLT_RAW on BSD/OS and OpenBSD.
|
||||
*/
|
||||
{ 14, WTAP_ENCAP_RAW_IP },
|
||||
|
||||
/*
|
||||
* 15 is:
|
||||
*
|
||||
* DLT_SLIP_BSDOS on BSD/OS;
|
||||
*
|
||||
* DLT_HIPPI on NetBSD;
|
||||
*
|
||||
* DLT_LANE8023 with Alexey Kuznetzov's patches for
|
||||
* Linux libpcap;
|
||||
*
|
||||
* DLT_I4L_RAWIP with the ISDN4Linux patches for libpcap
|
||||
* (and on SuSE 6.3);
|
||||
*
|
||||
* but we don't currently handle any of those.
|
||||
*/
|
||||
|
||||
/*
|
||||
* 16 is:
|
||||
*
|
||||
* DLT_PPP_BSDOS on BSD/OS;
|
||||
*
|
||||
* DLT_HDLC on NetBSD (Cisco HDLC);
|
||||
*
|
||||
* DLT_CIP with Alexey Kuznetzov's patches for
|
||||
* Linux libpcap - this is WTAP_ENCAP_LINUX_ATM_CLIP;
|
||||
*
|
||||
* DLT_I4L_IP with the ISDN4Linux patches for libpcap
|
||||
* (and on SuSE 6.3).
|
||||
*/
|
||||
#if defined(DLT_CIP) && (DLT_CIP == 16)
|
||||
{ 16, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
#endif
|
||||
#if defined(DLT_HDLC) && (DLT_HDLC == 16)
|
||||
{ 16, WTAP_ENCAP_CHDLC },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 17 is DLT_LANE8023 in SuSE 6.3 libpcap; we don't currently
|
||||
* handle it.
|
||||
* It is also used as the PF (Packet Filter) logging format beginning
|
||||
* with OpenBSD 3.0; we use 17 for PF logs unless DLT_LANE8023 is
|
||||
* defined with the value 17.
|
||||
*/
|
||||
#if !defined(DLT_LANE8023) || (DLT_LANE8023 != 17)
|
||||
{ 17, WTAP_ENCAP_OLD_PFLOG },
|
||||
#endif
|
||||
|
||||
/*
|
||||
* 18 is DLT_CIP in SuSE 6.3 libpcap; if it's the same as the
|
||||
* DLT_CIP of 16 that the Alexey Kuznetzov patches for
|
||||
* libpcap/tcpdump define, it's WTAP_ENCAP_LINUX_ATM_CLIP.
|
||||
* I've not found any libpcap that uses it for any other purpose -
|
||||
* hopefully nobody will do so in the future.
|
||||
*/
|
||||
{ 18, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
|
||||
/*
|
||||
* 19 is DLT_ATM_CLIP in the libpcap/tcpdump patches in the
|
||||
* recent versions I've seen of the Linux ATM distribution;
|
||||
* I've not yet found any libpcap that uses it for any other
|
||||
* purpose - hopefully nobody will do so in the future.
|
||||
*/
|
||||
{ 19, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
|
||||
/*
|
||||
* nettl (HP-UX) mappings to standard DLT values
|
||||
*/
|
||||
|
||||
{ 1, WTAP_ENCAP_NETTL_ETHERNET },
|
||||
{ 6, WTAP_ENCAP_NETTL_TOKEN_RING },
|
||||
{ 10, WTAP_ENCAP_NETTL_FDDI },
|
||||
{ 70, WTAP_ENCAP_RAW_IP },
|
||||
{ 101, WTAP_ENCAP_NETTL_RAW_IP },
|
||||
|
||||
/*
|
||||
* To repeat:
|
||||
*
|
||||
* If you need a new encapsulation type for libpcap files, do
|
||||
* *N*O*T* use *ANY* of the values listed here! I.e., do *NOT*
|
||||
* add a new encapsulation type by changing an existing entry;
|
||||
* leave the existing entries alone.
|
||||
*
|
||||
* Instead, send mail to tcpdump-workers@lists.tcpdump.org, asking
|
||||
* for a new DLT_ value, and specifying the purpose of the new value.
|
||||
* When you get the new DLT_ value, use that numerical value in
|
||||
* the "dlt_value" field of "pcap_to_wtap_map[]".
|
||||
*/
|
||||
};
|
||||
#define NUM_PCAP_ENCAPS (sizeof pcap_to_wtap_map / sizeof pcap_to_wtap_map[0])
|
||||
|
||||
int
|
||||
wtap_pcap_encap_to_wtap_encap(int encap)
|
||||
{
|
||||
unsigned int i;
|
||||
|
||||
for (i = 0; i < NUM_PCAP_ENCAPS; i++) {
|
||||
if (pcap_to_wtap_map[i].dlt_value == encap)
|
||||
return pcap_to_wtap_map[i].wtap_encap_value;
|
||||
}
|
||||
return WTAP_ENCAP_UNKNOWN;
|
||||
}
|
||||
|
||||
int
|
||||
wtap_wtap_encap_to_pcap_encap(int encap)
|
||||
{
|
||||
unsigned int i;
|
||||
|
||||
switch (encap) {
|
||||
|
||||
case WTAP_ENCAP_FDDI:
|
||||
case WTAP_ENCAP_FDDI_BITSWAPPED:
|
||||
case WTAP_ENCAP_NETTL_FDDI:
|
||||
/*
|
||||
* Special-case WTAP_ENCAP_FDDI and
|
||||
* WTAP_ENCAP_FDDI_BITSWAPPED; both of them get mapped
|
||||
* to DLT_FDDI (even though that may mean that the bit
|
||||
* order in the FDDI MAC addresses is wrong; so it goes
|
||||
* - libpcap format doesn't record the byte order,
|
||||
* so that's not fixable).
|
||||
*/
|
||||
return 10; /* that's DLT_FDDI */
|
||||
|
||||
case WTAP_ENCAP_PPP_WITH_PHDR:
|
||||
/*
|
||||
* Also special-case PPP with direction bits; map it to
|
||||
* PPP, even though that means that the direction of the
|
||||
* packet is lost.
|
||||
*/
|
||||
return 9;
|
||||
|
||||
case WTAP_ENCAP_FRELAY_WITH_PHDR:
|
||||
/*
|
||||
* Do the same with Frame Relay.
|
||||
*/
|
||||
return 107;
|
||||
|
||||
case WTAP_ENCAP_IEEE_802_11_WITH_RADIO:
|
||||
/*
|
||||
* Map this to DLT_IEEE802_11, for now, even though
|
||||
* that means the radio information will be lost.
|
||||
* Once tcpdump support for the BSD radiotap header
|
||||
* is sufficiently widespread, we should probably
|
||||
* use that, instead - although we should probably
|
||||
* ultimately just have WTAP_ENCAP_IEEE_802_11
|
||||
* as the only Wiretap encapsulation for 802.11,
|
||||
* and have the pseudo-header include a radiotap-style
|
||||
* list of attributes. If we do that, though, we
|
||||
* should probably bypass the regular Wiretap code
|
||||
* when writing out packets during a capture, and just
|
||||
* do the equivalent of a libpcap write (unfortunately,
|
||||
* libpcap doesn't have an "open dump by file descriptor"
|
||||
* function, so we can't just use "pcap_dump()"), so
|
||||
* that we don't spend cycles mapping from libpcap to
|
||||
* Wiretap and then back to libpcap. (There are other
|
||||
* reasons to do that, e.g. to handle AIX libpcap better.)
|
||||
*/
|
||||
return 105;
|
||||
}
|
||||
|
||||
for (i = 0; i < NUM_PCAP_ENCAPS; i++) {
|
||||
if (pcap_to_wtap_map[i].wtap_encap_value == encap)
|
||||
return pcap_to_wtap_map[i].dlt_value;
|
||||
}
|
||||
return -1;
|
||||
}
|
|
@ -0,0 +1,34 @@
|
|||
/* pcap-common.h
|
||||
* Declarations for code common to libpcap and pcap-NG file formats
|
||||
*
|
||||
* $Id$
|
||||
*
|
||||
* Wiretap Library
|
||||
* Copyright (c) 1998 by Gilbert Ramirez <gram@alumni.rice.edu>
|
||||
*
|
||||
* File format support for pcap-ng file format
|
||||
* Copyright (c) 2007 by Ulf Lamping <ulf.lamping@web.de>
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU General Public License
|
||||
* as published by the Free Software Foundation; either version 2
|
||||
* of the License, or (at your option) any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
*/
|
||||
|
||||
struct encap_map {
|
||||
int dlt_value;
|
||||
int wtap_encap_value;
|
||||
};
|
||||
|
||||
extern const struct encap_map pcap_to_wtap_map[];
|
||||
|
||||
extern int wtap_wtap_encap_to_pcap_encap(int encap);
|
|
@ -39,7 +39,8 @@
|
|||
#include "wtap-int.h"
|
||||
#include "file_wrappers.h"
|
||||
#include "buffer.h"
|
||||
|
||||
#include "libpcap.h"
|
||||
#include "pcap-common.h"
|
||||
|
||||
#if 0
|
||||
#define pcapng_debug0(str) g_warning(str)
|
||||
|
@ -62,8 +63,6 @@ pcapng_seek_read(wtap *wth, gint64 seek_off,
|
|||
int *err, gchar **err_info);
|
||||
static void
|
||||
pcapng_close(wtap *wth);
|
||||
static int wtap_pcapng_encap_to_wtap_encap(int encap);
|
||||
|
||||
|
||||
|
||||
/* pcapng: common block header for every block type */
|
||||
|
@ -1100,6 +1099,11 @@ pcapng_open(wtap *wth, int *err, gchar **err_info)
|
|||
|
||||
/* first block must be a "Section Header Block" */
|
||||
if(wblock.type != BLOCK_TYPE_SHB) {
|
||||
/*
|
||||
* XXX - check for damage from transferring a file
|
||||
* between Windows and UN*X as text rather than
|
||||
* binary data?
|
||||
*/
|
||||
pcapng_debug1("pcapng_open_new: first block type %u not SHB", wblock.type);
|
||||
return 0;
|
||||
}
|
||||
|
@ -1124,7 +1128,7 @@ pcapng_open(wtap *wth, int *err, gchar **err_info)
|
|||
}
|
||||
|
||||
/* read "Interface Description Block" specific settings */
|
||||
wth->file_encap = wtap_pcapng_encap_to_wtap_encap( wblock.data.if_descr.link_type );
|
||||
wth->file_encap = wtap_pcap_encap_to_wtap_encap( wblock.data.if_descr.link_type );
|
||||
wth->snapshot_length = wblock.data.if_descr.snap_len;
|
||||
|
||||
|
||||
|
@ -1147,7 +1151,7 @@ pcapng_open(wtap *wth, int *err, gchar **err_info)
|
|||
default:
|
||||
pcapng_debug1("pcapng_open: if_tsresol %u not implemented, timestamp conversion omitted",
|
||||
wblock.data.if_descr.if_tsresol);
|
||||
}
|
||||
}
|
||||
|
||||
return 1;
|
||||
}
|
||||
|
@ -1583,63 +1587,3 @@ int pcapng_dump_can_write_encap(int encap)
|
|||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
||||
static const struct {
|
||||
int dlt_value;
|
||||
int wtap_encap_value;
|
||||
} pcapng_to_wtap_map[] = {
|
||||
/*
|
||||
* These are the values that are almost certainly the same
|
||||
* in all libpcaps (I've yet to find one where the values
|
||||
* in question are used for some purpose other than the
|
||||
* one below, but...), and that Wiretap and Wireshark
|
||||
* currently support.
|
||||
*/
|
||||
{ 0, WTAP_ENCAP_NULL }, /* null encapsulation */
|
||||
{ 1, WTAP_ENCAP_ETHERNET },
|
||||
{ 6, WTAP_ENCAP_TOKEN_RING },
|
||||
{ 7, WTAP_ENCAP_ARCNET },
|
||||
{ 8, WTAP_ENCAP_SLIP },
|
||||
{ 9, WTAP_ENCAP_PPP },
|
||||
{ 10, WTAP_ENCAP_FDDI },
|
||||
{ 99, WTAP_ENCAP_SYMANTEC },
|
||||
{ 100, WTAP_ENCAP_ATM_RFC1483 },
|
||||
{ 101, WTAP_ENCAP_RAW_IP },
|
||||
{ 104, WTAP_ENCAP_CHDLC },
|
||||
{ 105, WTAP_ENCAP_IEEE_802_11 },
|
||||
{ 106, WTAP_ENCAP_LINUX_ATM_CLIP },
|
||||
{ 107, WTAP_ENCAP_FRELAY },
|
||||
{ 109, WTAP_ENCAP_ENC },
|
||||
{ 114, WTAP_ENCAP_LOCALTALK },
|
||||
{ 118, WTAP_ENCAP_CISCO_IOS },
|
||||
{ 119, WTAP_ENCAP_PRISM_HEADER },
|
||||
{ 121, WTAP_ENCAP_HHDLC },
|
||||
{ 122, WTAP_ENCAP_IP_OVER_FC },
|
||||
{ 127, WTAP_ENCAP_IEEE_802_11_WITH_RADIO },
|
||||
{ 129, WTAP_ENCAP_ARCNET_LINUX },
|
||||
{ 130, WTAP_ENCAP_JUNIPER_MLPPP },
|
||||
{ 131, WTAP_ENCAP_JUNIPER_MLFR },
|
||||
{ 133, WTAP_ENCAP_JUNIPER_GGSN },
|
||||
{ 135, WTAP_ENCAP_JUNIPER_ATM2 },
|
||||
{ 137, WTAP_ENCAP_JUNIPER_ATM1 },
|
||||
{ 138, WTAP_ENCAP_APPLE_IP_OVER_IEEE1394 },
|
||||
{ 139, WTAP_ENCAP_MTP2_WITH_PHDR },
|
||||
{ 140, WTAP_ENCAP_MTP2 },
|
||||
{ 141, WTAP_ENCAP_MTP3 },
|
||||
{ 142, WTAP_ENCAP_SCCP },
|
||||
{ 143, WTAP_ENCAP_DOCSIS }
|
||||
};
|
||||
#define NUM_PCAPNG_ENCAPS (sizeof pcapng_to_wtap_map / sizeof pcapng_to_wtap_map[0])
|
||||
|
||||
static int wtap_pcapng_encap_to_wtap_encap(int encap)
|
||||
{
|
||||
unsigned int i;
|
||||
|
||||
for (i = 0; i < NUM_PCAPNG_ENCAPS; i++) {
|
||||
if (pcapng_to_wtap_map[i].dlt_value == encap)
|
||||
return pcapng_to_wtap_map[i].wtap_encap_value;
|
||||
}
|
||||
return WTAP_ENCAP_UNKNOWN;
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in New Issue