https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5802
--- Comment #40 from Guy Harris <guy@xxxxxxxxxxxx> 2011-04-10 18:51:28 PDT ---
Note also that, for an arbitrary capture file, there's no guarantee that
Wireshark or TShark will read to the end of the file. For pcap and pcap-ng
files, and at least some other capture file formats, there's no data in the
file after the last packet. However, for example, in a Microsoft Network
Monitor capture file, there's a table of offsets into the file for each of the
packet records, which comes after the last packet, and there could be more data
after that packet, which Wireshark might not read in the sequential pass (it
has to read the offset table before it reads any packets, as it needs it in
order to know where the packets are in the file).
So, conceivably, even with the current code, we might not read all the way to
the trailer at the end of the gzip file. If we want to make sure we check the
CRC, we must, for example, scan all the way to the end of the compressed stream
when we close the file, and have the close routine report an error. (We
probably want to do so anyway, in case there's a delayed error we haven't
reported.)
The speedup patch + the "delay error reporting" patch still reports an error
when I try to read in the bad file, which it should do, but it does let me see
all the packets it managed to read in. (Delaying the error reporting might
also mean we can read a few more packets from a bad file, as the packet where
we first see the error will now be the first one where we can't get all the
data needed to decompress it.)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.