ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] FW: DISSECTOR_ASSERT_NOT_REACHED in WLCCP decode...

From: "Kevin A. Noll" <spamknoll@xxxxxxxxxxxxx>
Date: Thu, 31 May 2007 15:48:15 -0400
 
That makes perfect sense.

Thanks for the explanation.

--kan--


--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.		


-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: Thursday, May 31, 2007 3:36 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] FW: DISSECTOR_ASSERT_NOT_REACHED in WLCCP
decode...

No.

FT_UINT_BYTES means "a counted sequence of bytes" - i.e., a 1-byte to 4-byte
number, followed by that number of bytes.  If there's no count field,
FT_UINT_BYTES shouldn't be used.

For a sequence of bytes *not* preceded by a length value giving the number
of bytes in the sequence - or for a sequence of bytes where the length value
is to be treated as a separate field - FT_BYTES should be used.

The unsignedness of the bytes is implicit, as, for opaque sequences of
bytes, most if not all of the time you just want to display their hex
values, with the uppermost bit being just another bit.  The UINT in
FT_UINT_BYTES doesn't mean "the bytes are unsigned integers"; it means "the
sequence is preceded by an unsigned integer giving the number of bytes in
the sequence.

Unfortunately, FT_UINT_BYTES isn't documented in README.developer.  This is
a bug, and I'll look at fixing it.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev