Ethereal-dev: Re: [ethereal-dev] Re: [ethereal-users] Ethereal crash reading tcpdump '-r' fil
Sorry guys for not replying before. yesterday was a bad day. First fo
all, you are right, the log I sent you was from a Nokia box.
I though that it was the standard tcpdump from FBSD3.4. My fault. I
really apperciate your efforts trying to help me. Thanks.
My next job is trying to find out who had the brilliant idea of changing
the magic or from which platform this libcap is coming from.
If you need more bogus files don't hesitate to ask!! :-)
Thank you everybody.
marc.
Guy Harris wrote:
>
> 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.)
