On Tue, Jul 25, 2000 at 09:16:59AM +0200, Uwe Girlich wrote:
> It detects the "modified libpcap" but interprets the content totally wrong
> (one malformed IEEE frame, popup-window: the capture file appears to be
> damaged or corrupt).
Well, it appears that every single version of Alexey Kuznetzov's patches
to libpcap is different.
The ss990417 version, as appears in Red Hat 6.1, changes the per-packet
header but not the magic number; we already have a hack to check for
that.
The ss991029 version, which I hope is the version they picked up in Red
Hat 6.2, also changes the magic number.
The ss990915 version, which I suspect is the one SuSE picked up for 6.3,
also changed the magic number - but has some *additional* fields in the
per-packet header, which I infer were added for debugging purposes on
SMP machines. I shall have to find where to complain to SuSE, and ask
them to pick up the ss991029 version.
I just checked in a change that uses the hack for *all* libpcap capture
files, so as to distinguish between the four count 'em four different
file formats (normal, ss990417, ss990915, and ss991029); it appears to
read all the files I have, in all of those formats, including the one
you sent in what I assume is ss990915 format.
> Oh, and I had it wrong first, the SuSE tcpdump sees now also all loopback
> packets twice.
I suspect the packet tap mechanism sees the packet when you send it (and
diverts a copy to any tap sockets) *and* when you receive it (and
diverts *another* copy to any tap sockets).
I think I've seen that in other capture files and/or on the Debian (2.1,
hence a 2.0[.x] kernel) partition on my machine.
> > > Something like dissect_padding() in dissect_ip() to mark the bytes behind the
> > > IP data as padding would be nice.
> > This was suggested earlier; I'd like to come up with some way not to
> > oblige dissectors above the Ethernet dissector to know about this, as
> > 1) the padding is a characteristic of Ethernet, not of IP or IPX
> > or..., so dissectors above Ethernet shouldn't be the ones to
> > handle it;
> But dissect_ethernet() has no knowledge over the actual length of the data.
Perhaps it should be told, by the dissector below it, how much data that
dissector consumed, e.g. by having all dissectors return:
-1 if they are heuristic dissectors and the packet isn't one of
theirs;
the offset (within the tvbuff they were handed) of the first
byte that isn't theirs, otherwise.