Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3895] Save-As Nokia tcpdump corrupts the file

Date: Tue, 20 Dec 2011 22:22:11 -0800 (PST)
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.