[Guy Harris <guy@xxxxxxxxxxxx>]

On Wednesday, September 3, 2003, at 5:41 PM, Guy Harris wrote:

> Perhaps bytes 8550 through 8553 are a CRC-32?

Both files are 8557 bytes long, and, according to RFC 1952, the last 4 
bytes are the size of the uncompressed file, modulo 2^32, with a 4-byte 
CRC preceding them.

Bytes 8554, 8555, 8556, and 8557 are, in fact, 71587, which is the size 
of "snif6.cap" after the uncompression I did.

So that suggests that, in fact, the CRC *is* wrong in that file.  That 
won't be caught until you get to the end of the file, so the stuff done 
on the first pass through the capture file, such as the summary 
display, has no problem.  Furthermore, we have separate opens for the 
sequential read in the first pass and the random reads done 
subsequently, so the first random read works, too.  It appears that the 
sequential read doesn't check the CRC, but the random read does, so 
until you read to the end of the file, you don't see the bad CRC.

What we'd probably need is our own code for reading gzipped files, with 
an API that readers for particular file types can call to turn off CRC 
checking.