Wireshark-bugs: [Wireshark-bugs] [Bug 2778] New: When RTCP BYE reason string is ending in 32bit
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2778
Summary: When RTCP BYE reason string is ending in 32bit boundary
Wireshark need not emit expert info "Reason string is
not NULL-terminated"
Product: Wireshark
Version: 1.0.2
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: vinod7@xxxxxxxxx
Created an attachment (id=2129)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2129)
WinPcap of a sample RTCP packet
Build Information:
Version 1.0.2 (SVN Rev 25698)
Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.12.8, with GLib 2.14.6, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with ADNS, with Lua 5.1, with GnuTLS 2.3.8, with Gcrypt 1.4.1, with MIT
Kerberos, with PortAudio V19-devel, with AirPcap.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
--
When the RTCP BYE packet has a reason string which is not NULL
terminated ( because the octects in reason along with the reason
length already fills the packet to the next 32-bit boundary) Wireshark still
gives the expert info that
"Reason string is not NULL-terminated (see RFC3550, section 6.6)". But
to me it looks like RFC 3550
is not mandating that all BYE reasons be NULL terminated. Please see
the extract below from section 6.6.
"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."
Quoting from Mail Thread in Wireshark Dev.
~~
They also said
> The string has the same encoding as that described for SDES.
and what they say for SDES is
> Each chunk consists of an SSRC/CSRC identifier followed by a list
> of
> zero or more items, which carry information about the SSRC/CSRC.
> Each chunk starts on a 32-bit boundary. Each item consists of an
> 8-
> bit type field, an 8-bit octet count describing the length of the
> text (thus, not including this two-octet header), and the text
> itself. Note that the text can be no longer than 255 octets, but
> this is consistent with the need to limit RTCP bandwidth
> consumption.
>
> The text is encoded according to the UTF-8 encoding specified in
> RFC
> 2279 [5]. US-ASCII is a subset of this encoding and requires no
> additional encoding. The presence of multi-octet encodings is
> indicated by setting the most significant bit of a character to a
> value of one.
>
> Items are contiguous, i.e., items are not individually padded to a
> 32-bit boundary. Text is not null terminated because some multi-
> octet encodings include null octets. The list of items in each
> chunk
> MUST be terminated by one or more null octets, the first of which
> is
> interpreted as an item type of zero to denote the end of the list.
> No length octet follows the null item type octet, but additional
> null
> octets MUST be included if needed to pad until the next 32-bit
> boundary. Note that this padding is separate from that indicated
> by
> the P bit in the RTCP header. A chunk with zero items (four null
> octets) is valid but useless.
which describes null-padded strings, not null-terminated strings (in
fact, they explicitly say "Text is not null terminated because some
multi-octet encodings include null octets" - although they earlier say
the encoding is UTF-8, which *doesn't* include null octets in multi-
octet encodings).
I.e., RFC 3550 needs a little attention from an editor.
In any case, what Wireshark should do is treat the BYE Reason string
as null-padded, not as "null-terminated except when it isn't".
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
