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

5 files changed, 661 insertions, 652 deletions

diff --git a/wiretap/Makefile.common b/wiretap/Makefile.common
index 624473ee2a..d52ab163cb 100644
--- a/wiretap/Makefile.common
+++ b/wiretap/Makefile.common
@@ -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		\
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)
diff --git a/wiretap/pcap-common.c b/wiretap/pcap-common.c
new file mode 100644
index 0000000000..ed145ebc1d
--- /dev/null
+++ b/wiretap/pcap-common.c
@@ -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;
+}
diff --git a/wiretap/pcap-common.h b/wiretap/pcap-common.h
new file mode 100644
index 0000000000..efe11c476d
--- /dev/null
+++ b/wiretap/pcap-common.h
@@ -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);
diff --git a/wiretap/pcapng.c b/wiretap/pcapng.c
index da27654ad8..02fa063cd7 100644
--- a/wiretap/pcapng.c
+++ b/wiretap/pcapng.c
@@ -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;
-}
-