#include <epan/range.h>
#include <epan/frequency-utils.h>
-/* Needed for wtap_pcap_encap_to_wtap_encap(). Should we move it somewhere
- * else? */
-#include <wiretap/libpcap.h>
+#include <wsutil/encap_util.h>
#include "packet-frame.h"
#include "packet-eth.h"
ptvcursor_add_no_advance(csr, hf_8023_extension_flags_flag2, 4, TRUE);
ptvcursor_add(csr, hf_8023_extension_flags_flag3, 4, TRUE);
ptvcursor_pop_subtree(csr);
-
+
ptvcursor_add_with_subtree(csr, hf_8023_extension_errors, 4, TRUE, ett_8023_extension_errors);
ptvcursor_add_no_advance(csr, hf_8023_extension_errors_error1, 4, TRUE);
ptvcursor_add_no_advance(csr, hf_8023_extension_errors_error2, 4, TRUE);
ptvcursor_add(csr, hf_8023_extension_errors_error3, 4, TRUE);
ptvcursor_pop_subtree(csr);
-
+
ptvcursor_free(csr);
}
case PPI_CAPTURE_INFO:
ADD_BASIC_TAG(hf_capture_info);
break;
-
+
case PPI_AGGREGATION_EXTENSION:
dissect_aggregation_extension(tvb, pinfo, ppi_tree, offset, data_len);
break;
-
+
case PPI_8023_EXTENSION:
dissect_8023_extension(tvb, pinfo, ppi_tree, offset, data_len);
break;
{ &hf_aggregation_extension_interface_id,
{ "Interface ID", "ppi.aggregation_extension.interface_id",
FT_UINT32, BASE_DEC, NULL, 0x0, "Zero-based index of the physical interface the packet was captured from", HFILL } },
-
+
/* 802.3 Extension */
{ &hf_8023_extension_flags,
{ "Flags", "ppi.8023_extension.flags",
{ &hf_8023_extension_errors_error3,
{ "Error 3", "ppi.8023_extension.errors.error3",
FT_BOOLEAN, 32, TFS(&tfs_true_false), 0x0004, "Debug Error 3", HFILL } },
-
+
};
static gint *ett[] = {
#include "atm.h"
#include "erf.h"
#include "libpcap.h"
+#include <wsutil/encap_util.h>
/*
* Various pseudo-headers that appear at the beginning of packet data.
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 },
- { 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 },
-
- /*
- * 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;
}
return libpcap_get_i2c_pseudoheader(&i2c_hdr, pseudo_header);
-
+
}
static gboolean
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)
# generated from YACC or Lex files (as Automake doesn't want them in
# _SOURCES variables).
LIBWSUTIL_SRC = \
+ encap_util.c \
mpeg-audio.c \
privileges.c \
str_util.c
# Header files that are not generated from other files
LIBWSUTIL_INCLUDES = \
+ encap_util.h \
mpeg-audio.h \
privileges.h \
str_util.h
--- /dev/null
+/* encap_util.c
+ * Data Link Type (DLT) encapsulation utility definitions
+ *
+ * $Id: str_util.h 26131 2008-09-03 19:14:52Z guy $
+ *
+ * Wireshark - Network traffic analyzer
+ * By Gerald Combs <gerald@wireshark.org>
+ * Copyright 1998 Gerald Combs
+ *
+ * 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 "encap_util.h"
+#include <wiretap/wtap.h>
+
+/*
+ * 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 },
+ { 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 },
+
+ /*
+ * 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;
+}
+
+
--- /dev/null
+/* encap_util.h
+ * Data Link Type (DLT) encapsulation utility definitions
+ *
+ * $Id: str_util.h 26131 2008-09-03 19:14:52Z guy $
+ *
+ * Wireshark - Network traffic analyzer
+ * By Gerald Combs <gerald@wireshark.org>
+ * Copyright 1998 Gerald Combs
+ *
+ * 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.
+ */
+
+#ifndef __ENCAP_UTIL_H__
+#define __ENCAP_UTIL_H__
+
+int wtap_pcap_encap_to_wtap_encap(int encap);
+int wtap_wtap_encap_to_pcap_encap(int encap);
+
+#endif /* __ENCAP_UTIL_H__ */
\ No newline at end of file
;
EXPORTS
+; encap_util.c
+wtap_pcap_encap_to_wtap_encap
+wtap_wtap_encap_to_pcap_encap
+
+; file_util.c
+ws_stdio_fopen
+ws_stdio_freopen
+ws_stdio_mkdir
+ws_stdio_open
+ws_stdio_remove
+ws_stdio_rename
+ws_stdio_stat
+ws_stdio_unlink
+
+; mpeg-audio.c
+mpa_bitrate
+mpa_frequency
+mpa_layer
+mpa_padding
+mpa_samples
+mpa_version
+
; privileges.c
get_credential_info
get_cur_groupname
running_with_special_privs
started_with_special_privs
-; mpeg-audio.c
-mpa_bitrate
-mpa_frequency
-mpa_layer
-mpa_padding
-mpa_samples
-mpa_version
+; str_util.c
+ascii_strdown_inplace
+ascii_strup_inplace
; unicode-utils.c
utf_16to8
utf_8to16
-; file_util.c
-ws_stdio_open
-ws_stdio_rename
-ws_stdio_mkdir
-ws_stdio_stat
-ws_stdio_unlink
-ws_stdio_remove
-ws_stdio_fopen
-ws_stdio_freopen
-
-; str_util.c
-ascii_strdown_inplace
-ascii_strup_inplace
git.samba.org / obnox / wireshark / wip.git / commitdiff