On Tue, Jul 25, 2000 at 07:37:52AM +0200, Uwe Girlich wrote:
> I just tried (for the first time) to capture traffic on the loopback interface
> on a SuSE Linux 6.3 system (kernel 2.2.16, current ethereal (one hour old),
> libpcap 0.5). I found that ping 127.0.0.1 gave me 2 identical echo request
> ICMP packets and two identical answers. Is this a known error? I could also
> reproduce this with other local programs. The stock SuSE tcpdump had not
> this problem
This may be a difference between libpcap 0.5 (which still has the Tired
Old Linux SOCK_PACKET code) and the SuSE tcpdump (which sounds, from
what you say about the magic number, as if it has Alexey Kuznetzov's
patches, which use PF_PACKET/SOCK_RAW).
It may be that linking Ethereal either with the stock SuSE libpcap, or
with the current libpcap in tcpdump.org's CVS tree (or one of the recent
snapshots), makes this problem go away, as both of them use PF_PACKET
rather than SOCK_PACKET.
> (but uses the wrong magick 0xa1b2cd34 and a different layout in
> the file, so I could not read it in ethereal.
If Ethereal can't read that capture file, that's a bug; it not only
includes code to handle 0xa1b2cd34, it even includes code to attempt to
handle earlier versions of Kuznetzov's patches (as appear in, for
example, Red Hat 6.1) which change the layout but do *not* change the
magic number.
What happened when you tried to read it with Ethereal?
> 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;
2) there are a fair number of dissectors that would have to know
about this if it were done at the network layer.
