OK, I understand the setup and what the situation is. I'll monitor the
future releases of ethereal/libpcap/tcpdump for when the approach you
propose gets in there. BTW, for tcpdump on my target machine, it
actually is running now instead of segmentation faulting. Previously I
had never had it working on that machine. So if anything I did step
forward with that, I just am not able to tcpdump -i atm0. I'll try more
on that later in the week.
Thanks again for your help,
Carl
Guy Harris wrote:
>
> 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.)
--
Carl Klatsky Ph: 732.530.4471
3NO Systems, Inc. Fax: 732.530.2110
http://www.3no.com e-mail: cklatsky@xxxxxxx