On Mon, Aug 21, 2000 at 07:51:36PM -0400, Carl Klatsky wrote:
> 4) Since I rebuilt tcpdump from source, I could now run it directly on
> target machine without getting the segmentation fault. I tried what you
> had suggested earlier about using tcpdump to create the capture file and
> read it in ethereal. The problem is when I run tcpdump -i atm0, I get:
>
> User level filter, protocol ALL, raw packet socket
> tcpdump: unknown data link type 0x12
Which suggests that a data link type of 18 was somehow introduced by
whatever weird libpcap-from-Mars (0.4*a6*? It's *REALLY* depressing how
many libpcap/tcpdump combinations are out there based on 0.4a6/3.4a6 -
and even some patches are, I think, to 0.4a5/3.4a5! Did the folks at
SuSE not realize that LBL came out with a later 0.4/3.4 release *years*
ago?) SuSE are using.
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 */
Boy, this motivates me even *more* to clean up the libpcap stuff, so
that no libpcap file has any DLT value greater than 10 in it, and so
that a set of values, maintained *STRICTLY* by tcpdump.org (as in "if
you want a new value for a new link layer type, ask us, and we'll give
you one really quickly - that's the carrot; the stick is that if you
don't, and if you come up with your own values, we make no guarantee
that we won't give those values to somebody else, and you'll just have
to suffer"), is used for all link-layer types other than 0 (DLT_NULL)
through 10 (DLT_FDDI), so that what goes into the file header and is
returned by "pcap_datalink()" *isn't* a DLT_ value, it's a value in a
range maintained by tcpdump.org. (Back when libpcap was first done, it
should've been done that way, so that DLT_ values, which are supplied by
the OS and may well differ from OS to OS, aren't used, but are mapped to
values that belong to libpcap, just as DLPI DL_ values are, and just as
Linux ARPHRD_ value are, and....)
All four of the BSDs (BSD/OS and {Free,Net,Open}BSD) all have cases
where the same numerical value is used for different purposes in
different OSes.
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*.
Grrr....
I am Sorely Tempted to have Wiretap
1) if built on a system without libpcap, simply give up in
disgust on most of the ambiguous DLT_ values, as there's no
way for it to figure out what libpcap on that platform would
use, as there *isn't* a libpcap on that platform;
2) if built on a system with libpcap, include <pcap.h> and use
the DLT_ values therein to pick an interpretation for the
ambiguous types.
If I manage to bash such a hideous workaround into shape, I'll send it
around.
(As for tcpdump no longer working because it lacks the appropriate
patches, I'd suggest you install the binaries from your CD - hopefully
that'll install an unwedged version.)