Oh! I didn't realize you weren't using the frame table. Yes, it is very
important that you do.
The code I wrote for both NETMON 1 and 2 tries to use the frame table, and
only does a step-by-step progression through the file if it can't find a
frame table. That allows it to both compensate for these types of files
using the frame table, and also rescue frames from files that have been
truncated.
=====================================
Tim Farley
Software Engineer
tfarley@xxxxxxx
Internet Security Systems, Inc.
(678) 443-6000 / Direct Dial (678) 443-6189 / fax (678) 443-6479
http://www.iss.net
ISS CONNECT 2000
International User Group and Information Security Summit
March 19-24, 2000 http://connect.iss.net
REGISTER TODAY!
=====================================
>-----Original Message-----
>From: Guy Harris [mailto:guy@xxxxxxxxxx]
>Sent: Wednesday, March 22, 2000 4:46 PM
>To: Farley, Tim (ISSAtlanta)
>Cc: 'Fabrizio Ammollo'; ethereal-dev@xxxxxxxx
>Subject: Re: [ethereal-dev] MS Netmon 2.x trace which gives "corrupt
>file" when loaded
>
>
>> I also get errors when I unpack those files:
>>
>> gzip: netmon.txt.gz: invalid compressed data--crc error
>> gzip: VRU.CAP.gz: invalid compressed data--format violated
>
>Bizarre - it appeared to have survived the mail path to my home ISP, at
>least; I'll have to check whether the copy I received at work was also
>ungzippable.
>
>> Would be glad to look at them, as I was the one who provided
>the info on the
>> NETMON 2.x format in the first place.
>
>It turns out that those captures did not always have packet
>N+1 start at
>the next byte following packet N (the glitches were, as I remember, on
>32K boundaries, as per your hypothesis about the way NetMon 2 does
>captures); I checked in a change to the NetMon file reader to read the
>entire frame table and use the offsets in the frame table to find the
>frames, and it allowed him to read the file.
>