--- Begin Message ---On Aug 4, 2020, at 1:28 PM, Francois-Xavier Le Bail <devel.fx.leb...@orange.fr> wrote:> lane_if_print() in print-lane.c > (Added by 77b2a4405561467f66a3dfb0f8ce2b0eaa5ebaf9 in Sun Nov 21 1999 "print > of ATM LanEmulation") > is called for DLT_LANE8023: > > print.c-56-#ifdef DLT_LANE8023 > print.c:57: { lane_if_print, DLT_LANE8023 }, > print.c-58-#endif > (Added by 777892a591065d32fb8744675574f9214398283a in Sun Nov 21 1999 "add > lane and cip printing") > > But DLT_LANE8023 was never defined in libpcap nor tcpdump. A comment in pcap/dlt.h says: /* * 17 was used for DLT_PFLOG in OpenBSD; it no longer is. * * It was DLT_LANE8023 in SuSE 6.3, so we defined LINKTYPE_PFLOG * as 117 so that pflog captures would use a link-layer header type * value that didn't collide with any other values. On all * platforms other than OpenBSD, we defined DLT_PFLOG as 117, * and we mapped between LINKTYPE_PFLOG and DLT_PFLOG. * * OpenBSD eventually switched to using 117 for DLT_PFLOG as well. * * Don't use 17 for anything else. */ However, I downloaded ISO disk 6 from https://archive.org/download/SuSE6.3-full mounted it (macOS diskimages-helper for the win!), copied libpcap-0.4a6.spm, turned it into a cpis file with rpm2cpio, and extracted the contents; I can't see DLT_LANE8023 in either the source (which may be a vanilla version of libpcap 0.4a6, often mistakenly thought to be the last libpcap from LBL - 0.4 non-alpha was) or in the SuSE patch, so either 1) there was no DLT_LANE8023 in SuSE 6.3; 2) there was, but it wasn't in libpcap; 3) there was, but it wasn't in *that* libpcap, it was in some *other* libpcap (but I couldn't find any other libpcap); 4) that's not an image of SuSE 6.3. So I checked my mailbox, and found a message from 2000(!) to the ethereal-dev mailing list: https://www.wireshark.org/lists/ethereal-users/200008/msg00159.html in which, among other things, I said: > So I downloaded an RPM from SuSE's Web site, and the "bpf.h" in it says: > > /* Warning: not binary compatible with ANK libpcap !!! */ > #define DLT_LANE8023 17 /* LANE 802.3(Ethernet) */ > #define DLT_CIP 18 /* ATM Classical IP */ and > And then, in Linuxland: > > We have Alexey's patches - which may just have picked stuff up > from elsewhere - which add > > #define DLT_LANE8023 15 /* LANE 802.3(Ethernet) */ > #define DLT_CIP 16 /* ATM Classical IP */ > > We have the ISDN4Linux patches, which add > > #define DLT_I4L_RAWIP 15 /* isdn4linux: rawip */ > #define DLT_I4L_IP 16 /* isdn4linux: ip */ > > And now we have SuSE's, which add the ISDN4Linux stuff, and then > add the stuff from Alexey's patches *but with different > numbers from the ones in his patches*. I'm not sure what RPM that was, but the idea was, presumably, that *if* you built tcpdump on a system that *did* define DLT_LANE8023 in *its* libpcap, and used *its* libpcap, it could print packets that used DLT_LANE8023. ("Alexey"/"ANK" is Alexey Kuznetzov who, among other things, created the "turbopacket" patch to the Linux PF_PACKET socket code; that eventually got into the mainline kernel - the "T" in "TPACKET_V[123]" stands, I think, for "turbo".) > What to do with this? As far as I know, neither DLT_LANE8023 nor DLT_CIP are still around in any Linux distribution, so nuking support for that's OK with me. I'm not seeing any support for either of them in Wireshark. Current OpenSuSe Leap 15.2 does not have DLT_LANE8023 or DLT_CIP. Is there any reason to keep the code to handle those DLT_ values around?
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
