> "libpcap 0.4a6" as in "libpcap 0.4a6 downloaded from ftp.ee.lbl.gov
> before they came out with the final 0.4 release, and completely
> unmodified", or "libpcap 0.4a6" as in "a version of libpcap 0.4a6 that
> has had the patches from the 'extra' directory of the Linux ATM
> distributions from
>
> http://lrcwww.epfl.ch/linux-atm/
>
> applied"?
Or "libpcap 0.4a6" as in "yet another Linux distribution that's picked
Alexey Kuznetzov's patches"; SuSE picked up an older version of those
patches (and, in the process, made their tcpdump's capture file format
incompatible with that of Red Hat 6.1 and 6.2, as far as I know, as well
as with standard libpcap capture file format, but give it the same magic
number as 6.2; Ethereal 0.8.10 and later can read all four formats, by
dint of some really disgusting heuristics that ferret out the truth even
though the magic number isn't sufficient for that).
Those patches - even the latest ones - also introduce two DLT_ values
for LANE and Classical IP that collide with other DLT_ values; Ethereal
refuses to read any of them because it doesn't know whether DLT_ values
of 15 and 16 mean what they are on OpenBSD and BSD/OS, on FreeBSD, or on
NetBSD - and, now, they mean something else gain on some Linux
distributions.
This may have come from earlier Linux ATM patches, so even *without* the
Kuznetzov patches things may still be FUBAR.
Sigh.
I need to crank out the changes I was thinking about to libpcap and
tcpdump to banish *all* the colliding DLT_ values from the headers of
capture files, so that all subsequent libpcap encapsulation types come
from a space over which tcpdump.org can, hopefully, exert more control,
avoiding ********* ************ such as this.
I'll also contemplate making the interpretation of those particular DLT_
values platform-dependent - there's no way (short of throwing in Even
More Heuristics, assuming there are even heuristics that *can*
distinguish between them), so we might as well just make Ethereal
capable of reading those files on the platforms on which they're
generated - which may fix this particular problem.
(Unfortunately, it appears that the ISDN4Linux patches also use 15 and
16 as DLT_ types, so if you apply both the ISDN4Linux and Linux ATM
patches, you are Well And Truly Screwed for libpcap, and programs that
use it, such as tcpdump and Ethereal. What a mess....)