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] Terminating NULL chraracter in RTCP Byereason string

From: "Neil Piercy" <Neil.Piercy@xxxxxxxxxxxx>
Date: Tue, 5 Aug 2008 18:20:58 +0100
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx 
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
> 
> On Aug 5, 2008, at 7:23 AM, Vinod M wrote:
> 
> > "Optionally, the BYE packet MAY include an 8-bit octet 
> count followed 
> > by that many octets of text indicating  the reason for 
> leaving, e.g., 
> > "camera malfunction" or "RTP loop detected".
> >  The string has the same encoding as that described for SDES.
> >  If the string fills the packet to the next 32-bit boundary, the 
> > string is not null terminated.

The real problem in the spec is here - the leap from "octets of text" to
"string".

> It sounds as if whoever wrote RFC 3550 needs to learn the 
> difference between the words "padded" and "terminated" - they 
> probably meant to say that the string is null-*padded* to a 
> 4-byte boundary.

Maybe they did know the diference, and maybe they didn't, but what they
actually said was:

> >  If the string fills the packet to the next 32-bit boundary, the 
> > string is not null terminated.

i.e. they have defined a case in which a "string" is not null terminated
(i.e. is a sequence of non-null characters only), so Wireshark should
not object to the string not being null terminated in this case.

Neil