diff options
author | Guy Harris <guy@alum.mit.edu> | 2009-04-27 09:28:28 +0000 |
---|---|---|
committer | Guy Harris <guy@alum.mit.edu> | 2009-04-27 09:28:28 +0000 |
commit | 18a3b0659c209a2e0121eacd640b75e6c1c3b87d (patch) | |
tree | cefeac416ed607a73d27b6423f1536f4c37b4c5b /wiretap/libpcap.c | |
parent | 2b36f00d1c397cfabd6442d3d9c1abc81e31702c (diff) |
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
Diffstat (limited to 'wiretap/libpcap.c')
-rw-r--r-- | wiretap/libpcap.c | 588 |
1 files changed, 1 insertions, 587 deletions
diff --git a/wiretap/libpcap.c b/wiretap/libpcap.c index 8cbde58113..d4343ab06f 100644 --- a/wiretap/libpcap.c +++ b/wiretap/libpcap.c @@ -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) |