Wireshark-bugs: [Wireshark-bugs] [Bug 3895] Save-As Nokia tcpdump corrupts the file
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3895
--- Comment #10 from Guy Harris <guy@xxxxxxxxxxxx> 2011-12-20 22:22:09 PST ---
This is why there is a long comment in pcap.h (and in the internal-to-libpcap
pcap-int.h) pleading with people *NOT* to put out pcap-like files in a
different format from standard pcap without changing the magic number. The
fine folks at Nokia (or at a company they bought) made that mistake; they
introduced a new format that adds 4 more bytes of information after the record
header for every packet, but didn't bother to change the magic number.
This means that Wireshark *C*A*N*N*O*T* reliably detect Nokia libpcap files!
At *best*, it can try to read a file as if it were a normal pcap file (or like
some *other* such unfortunate formats) and, if that fails, *assume* it's a
Nokia libpcap file.
The only way the attempt to read a Nokia pcap file as if it were a normal pcap
file would fail if there were more than 1 packet in the file and the attempt to
read the second packet returned a bogus record header (e.g., a huge capture
length) due to the code assuming the record header were 32 bytes (as it is for
a normal pcap file) rather than 36 bytes (as it is for a Nokia pcap file), so
that the attempt to read the header for the second packet starts 4 bytes
*before* the actual header.
This means, obviously, that this doesn't work if you have only one packet in
the file.... I.e., Wireshark is *completely incapable* of distinguishing a
Nokia pcap file from a normal pcap file if it has only one packet in it,
unless, by some stroke of luck, for the link-layer header type for the file,
*NO* value for the extra 4 bytes in a Nokia pcap file can *EVER* be a valid
first 4 bytes of a link-layer header - we will not ever allow a heuristic that
mistakenly considers standard pcap files to be Nokia pcap files.
Note that this also means that if you try to save anything other than a Nokia
pcap file as a Nokia pcap file, you will get some arbitrarily-chosen value in
those extra 4 bytes, unless somebody has a document describing what those
values are *and* there's a value that can be written if whatever metadata would
be stored there is absent.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
