https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14595
Guy Harris <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|IN_PROGRESS |RESOLVED
--- Comment #5 from Guy Harris <[email protected]> ---
(In reply to Martin Kaiser from comment #1)
> For each packet, this pcap file has 4 additional bytes between packet header
> and the actual packet data.
>
> Wiretap's libpcap code tries to figure out the number of bytes between
> packet header and packet data (there are none by default).
No, it tries to figure out what the format of the packet header is; as
indicated, some developers wrote code that writes pcap-like files with
non-standard pcap packet headers but with the standard pcap magic number, so we
have to go through all this heuristic nonsense to work around their unfortunate
choice to do so.
> We get it wrong
> for this file and assume that there are 8 additional bytes. The reading gets
> out of sync and we mis-interpret the packet headers.
>
> I'll look into this some more as time permits.
>
> We might be able to improve the code that detects how big the gap is between
> header and packet data. At the moment, we iterate over the possible gap
> sizes
Actually, we iterate over all the types of "this isn't a standard pcap file but
we used the standard pcap magic number - shame on us" packet headers, one
courtesy of a Linux developer (who later picked a different magic number, yay,
but then proceeded to use the *new* magic number for two different header
formats...) and one courtesy of Nokia or possibly a company Nokia bought.
The Nokia format also has 4 additional bytes, so perhaps this is Nokia's fault
(or whoever first developed the device that produced that format).
> until we're able to read the first two packets without errors. We
> could increase this number (the sample file's problems start in packet 3...).
I've checked in a change to boost the maximum number of packets we check to 3,
and made it a #define so we can increase it if necessary.
> BTW the pcap file dissector doesn't handle additional bytes between packet
> header and packet data at all.
We'd have to do similar heuristics there.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:[email protected]?subject=unsubscribe
