Ethereal-dev: Re: [ethereal-dev] Re: [ethereal-users] Ethereal crash reading tcpdump '-r' file
On Wed, Sep 13, 2000 at 02:27:05PM -0700, Guy Harris wrote:
> > Here's a diff against the current CVS, and it might actually apply
> > cleanly against your 0.8.10, to guard against ethereal blowing up on
> > the file. The capture file is indeed very different than what ethereal
> > expects.
>
> It's also different from what standard tcpdump expects:
>
> tooting$ tcpdump -r /u/guy/captures/barfolino.pcap
> 18:22:41.289231 8e:6:36:32:0:a0 1:d9:bf:bf:0:a0 8e06 294:
> 80aa 0800 4500 0118 0ce9 0000 4011 55e9
> 0a01 0201 0a01 0101 01f4 01f4 0104 cf94
> fefa fee7 f500 0000 0000 0000 0000 0000
> 0110 0200 0000 0000 0000 00fc 0d00 00cc
> 0000 0001 0000 0001 0000 00c0 0001 0804
> fefa fee7 f500 0000 0300 002c 0001 0000
> 8001 0005 8002 0002 8003 0002 8004 0001
> 800b 0002 000c 0004 000f 4240 800b 0001
> 800c 05dc 0300 002c 0101 0000 8001 0005
> 8002 0001 8003 0002 8004 0001 800b 0002
> 000c 0004 000f 4240 800b 0001 800c 05dc
> 0300 002c 0201 0000 8001 0001 8002 0002
> 8003 0002 8004 0001 800b 0002 000c 0004
> 000f 4240 800b 0001 800c 05dc 0000 002c
> 0301 0000 8001 0001 8002 0001 8003 0002
> 8004 0001 800b 0002 000c 0004 000f 4240
> 800b 0001 800c 05dc 0000 0014 0e58 d577
> 4df6 0200 7d0b 0244
> tcpdump: pcap_loop: bogus savefile header
>
> I'll have to try it at home, on my FreeBSD 3.4 machine, but FreeBSD
> 3.4's libpcap isn't, as I remember, significantly different from the
> vanilla one.
The capture file didn't come from the standard tcpdump that comes with
FreeBSD 3.4 on x86, because the standard tcpdump on FreeBSD 3.4 on my PC at
home thinks it's bogus:
% uname -srp
FreeBSD 3.4-RELEASE i386
% which tcpdump
/usr/sbin/tcpdump
% tcpdump -r barfolino.pcap
18:22:41.289231 8e:6:36:32:0:a0 1:d9:bf:bf:0:a0 8e06 294:
80aa 0800 4500 0118 0ce9 0000 4011 55e9
0a01 0201 0a01 0101 01f4 01f4 0104 cf94
fefa fee7 f500 0000 0000 0000 0000 0000
0110 0200 0000 0000 0000 00fc 0d00 00cc
0000 0001 0000 0001 0000 00c0 0001 0804
fefa fee7 f500 0000 0300 002c 0001 0000
8001 0005 8002 0002 8003 0002 8004 0001
800b 0002 000c 0004 000f 4240 800b 0001
800c 05dc 0300 002c 0101 0000 8001 0005
8002 0001 8003 0002 8004 0001 800b 0002
000c 0004 000f 4240 800b 0001 800c 05dc
0300 002c 0201 0000 8001 0001 8002 0002
8003 0002 8004 0001 800b 0002 000c 0004
000f 4240 800b 0001 800c 05dc 0000 002c
0301 0000 8001 0001 8002 0001 8003 0002
8004 0001 800b 0002 000c 0004 000f 4240
800b 0001 800c 05dc 0000 0014 0e58 d577
4df6 0200 7d0b 0244
tcpdump: pcap_loop: bogus savefile header
If, however, I modify Ethereal to think that, the fact that this file
has the magic number for standard unmodified libpcap nonwithstanding,
each record has an extra 3 bytes of crap gratuitiously stuck at the end
of the per-packet header (right before the packet data), the capture
appears to consist of:
4 ISAKMP packets between 10.1.2.1 and 10.1.1.1;
a SYN packet, to the LDAP port, from 10.1.2.1 to 10.1.7.7;
an ICMP Destination Unreachable from 10.1.2.2 to 10.1.2.1;
2 more ISAKMP packets;
another SYN;
another ICMP Destination Unreachable;
several more ISAKMP packets.
If possible, Mr. Palomar should try to track down the author of the
version of libpcap with which the version of tcpdump that generated the
capture was linked, and inform him or her that changing the format of
the file header, or the per-packet header, in a tcpdump file, without
changing the magic number of the file, is a Very Very Very Very Very
Very Very Very Very Very Very Very Very Bad Idea, as it makes standard
boring vanilla tcpdump as appears on zillions of UNIX boxes (and some
number of Windows boxes) unable to read those capture files, and makes
tons of other programs that read tcpdump files, e.g. libpcap and tons
of other packet analysis programs, incapable of reading them.
(As I vaguely remember somebody asking, either on one of the Ethereal
lists or on the tcpdump-workers list - or perhaps somewhere else - about
reading capture files from some piece of Nokia hardware, which I think
was some kind of security hardware, i.e. the sort of products mentioned
on the site to which http://www.iprg.nokia.com/ redirects you, said
person may work for the part of Nokia for which Mr. Palomar works.)
I shall perhaps look into seeing whether I can extend the gross
heuristics that Ethereal performs to try to cope with the N mutant
variants of Alexey Kuznetzov's libpcap patches to also handle this
particular hacked-to-pieces libpcap format; I make no guarantees that it
can be done, and I make no guarantees that it'll be done soon. (Yes,
I'm in a bad mood; take a look at the "wiretap/libpcap.c" and
"wiretap/libpcap.h" files in the Ethereal source to see *why* libpcap
capture files, and the wild abandon with which people have mutated it,
puts me in a bad mood. Attempts to defend said wild abandon, or those
mutations that failed to change the magic number to make it possible to
recognize those mutations solely by looking at the file's magic number,
will only worsen my mood; they will elicit no sympathy.)
