ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] Bug in compressed sniffer file decode

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Greg Morris" <gmorris@xxxxxxxxxx>
Date: Thu, 11 Sep 2003 08:26:36 -0600
Yes,
 
All 3 files open without a problem.
 
Greg

>>> Guy Harris <guy@xxxxxxxxxxxx> 9/11/2003 3:50:42 AM >>>
On Mon, Sep 08, 2003 at 10:41:06AM -0600, Greg Morris wrote:
> Well, The files do not cmp well. See attached. It's not just the header
> that is different it appears to be different throughout the files.

That's probably the result of some incorrect step in the process.

I took your original Snif6.caz and did

    gzcat Snif6.caz >Snif6.cap
    gzip <Snif6.cap >Snif6x.caz

and compared them with "cmp -l", and got

     5   0  61
     6   0 104
     7   0 140
     8   0  77
    10  13   3
  8550 253 243
  8551  10 364
  8552 270 174
  8553 317 150

As in my earlier message, the first 4 bytes are probably the original
file time stamp, the next byte is probably the OS on which the
compression was done, and the last 4 bytes are the CRC-32.

I've attached all three files - what does the Sniffer do when you read
them?

Presumably Snif6.caz works, as it was written by the Sniffer, and
Snif6.cap *should* work, as it's been forcibly decompressed by running
"gzcat" rather than "gunzip" and ignoring the "invalid compressed
data--crc error" complaint.

The question is whether Snif6x.caz works - if so, then the Sniffer is
apparently ignoring the CRC (and perhaps producing a bad CRC when
generating compressed files), and, if it doesn't work, it's probably
that the Sniffer is using some non-standard CRC algorithm (or a buggy
one in both the generation *and* the checking).