All three files open in Sniffer Distributed Pro Version 4.20.033. So it seems that the CRC is ignored.
Jeff Foster [EMAIL PROTECTED] -----Original Message----- From: Guy Harris [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 4:51 AM To: Greg Morris Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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. ****
