Wireshark-bugs: [Wireshark-bugs] [Bug 3856] The Shomiti wireless format has been modified
Date: Wed, 16 Sep 2009 19:48:48 -0700 (PDT)

--- Comment #7 from Guy Harris <[email protected]>  2009-09-16 19:48:47 PDT ---
I've checked in some changes to

    1) explicitly check for a header length < 8 and report that as a corrupted

    2) not skip the rest of the header by reading into a fixed-length buffer,
as there's no absolute 100% guarantee that the header length won't be greater
than 8 + the buffer length;

    3) ask some questions about the header.

The questions are:

    The header length doesn't include the length itself, right?  (The header
structure is 4 bytes of padding/length and 8 bytes of information.)

    Is there anything in those other 3 bytes of padding/length?  Is that field
a 4-byte big-endian length field (so that the other 3 bytes would be 0 in most
if not all cases), or is it 2 bytes of other stuff followed by a 2-byte
big-endian length field, or is it 3 bytes of other stuff followed by a 1-byte
length field?  If it's not a 4-byte length field, is there anything meaningful
in the other bytes?

    Is there any useful information after the 8 bytes of header data that we
currently process?

    Can the header be less than 8 bytes long, so that not all the information
we currently read is there?  For example, are there non-802.11 captures with a
shorter pseudo-header?

Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.