Comment # 27
on bug 9652
from Guy Harris
(In reply to comment #12)
> hmm, strange file
Perhaps it's the result of fuzzing another such strange file? Fuzzing, as far
as I know, affects packet contents, but *not* record headers in the capture
file, so it shouldn't turn a readable file into an unreadable file, it should
just turn a readable file into an equally readable file with different packet
contents (randomly modified).
It also shouldn't turn a JPEG file:
$ file ~/captures/wireshark-menagerie/10052-wireshark_vs_omnipeek.jpg
/Users/gharris/captures/wireshark-menagerie/10052-wireshark_vs_omnipeek.jpg:
JPEG image data, JFIF standard 1.01
into a pcap-ng file!
> we currently have a hard-coded limit of 64k per wiretap block
>
> I'd say tshark's behaviour is ok. We could consider raising wiretap's 64k
> limit, I don't know why that was set...
It matches libpcap's limit when reading capture files (which dates back many
many many years, before pcap-ng even existed). We probably want *some* limit,
given that the captured-length field in pcap, pcap-ng, and at least some other
capture file formats is 32 bits, and we'd probably prefer a failure mode other
than "allocating enough memory to eat up almost all of the address space" (as
would be the case for ILP32) for files with bogusly (or maliciously) large
captured lengths.
No, the limit doesn't *have* to be 65535; however, *any* limit (less than
2^32-1) would still mean that it would be possible to construct
pcap/pcap-ng/etc. files that would get this error.
The underlying bug is probably that fuzzing 10052-wireshark_vs_omnipeek.jpg
produced a pcap-ng file. Perhaps we need to have a WinPcap API that lets the
caller determine whether the file is a capture file (with per-packet record
headers) or not (such that the file *is* the packet), as, in the latter case,
fuzzing the file could produce a file of a different type, and have editcap
refuse to fuzz those files.
You are receiving this mail because:
- You are watching all bug changes.