https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6663
--- Comment #5 from Guy Harris <guy@xxxxxxxxxxxx> 2011-12-12 15:35:02 PST ---
I'd say there are two possible problems here:
1) we might not be parsing the current version of *Peek-ng format
correctly;
2) we aren't protecting against capture files with "reported length" values
> 2^31 - 1.
2) probably shouldn't be done in the Wiretap library, as there's nothing
inherently wrong with a "reported length" of, say, 2^32-1; it's only a problem
because we currently treat lengths in tvbuffs as signed, so a "reported length"
> 2^31 - 1 would appear negative, and the tvbuff creator would return NULL.
That should probably be handled in the code that creates the initial tvbuff for
the frame.
1) is another matter; I would not be surprised to find that 0xffffffff here
means "gee, I don't know how big the frame was on the wire" or something such
as that (which seems bogus - why not just omit the tag if you don't know? -
unless it's a backwards-compatibility hack for versions of *Peek that required
that tag to be present). I'll ask Laurent for a text-file dissection of that
capture from *Peek, to see if we can do more reverse engineering (and ask him
to file a separate bug on that).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
