All three files open in Sniffer Distributed Pro Version 4.20.033.
So it seems that the CRC is ignored.
Jeff Foster
jfoste@xxxxxxxxxxxx
-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
Sent: Thursday, September 11, 2003 4:51 AM
To: Greg Morris
Cc: gram@xxxxxxxxxxxxxxx; ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] Bug in compressed sniffer file decode
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).
***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
****
