http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1279
Summary: Negative values for RTCP round trip delay cannot be
stored in guint32
Product: Wireshark
Version: 0.99.4
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: trav.ethereal@xxxxxxxxxxxxxxx
Build Information:
Version 0.99.4 (SVN Rev 19757)
Copyright 1998-2006 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.6.9, with GLib 2.6.6, with WinPcap (version unknown), with
libz 1.2.3, with libpcre 6.4, with Net-SNMP 5.3.1, with ADNS, with Lua 5.1,
with
GnuTLS 1.5.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio <= V18, with
AirPcap.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 3.1
(packet.dll version 3, 1, 0, 27), based on libpcap version 0.9[.x], without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
--
When Wireshark calculates roundtrip delay based on the RTCP DLSR and
timestamps, it appears to store the result in an unsigned 32-bit int (guint32).
Some equipment generates invalid RTCP DLSR values resulting in a negative value
for roundtrip delay. Wireshark is displaying a number in the 2^32-x range (e.g.
Roundtrip Delay(ms): 4294966423). While this is theoretically impossible
(unless traffic somehow takes longer to get to Wireshark than it does to get to
the RTCP endpoint), the value displayed is misleading and doesn't aid in
troubleshooting the issue unless one understands why Wireshark may be
displaying the large value. Would it be possible to store this in a signed int,
instead? I would think that 24days+ would be a reasonable capacity for this
variable.
STEPS TO REPRODUCE:
Basically, the situation that triggers this is when the delta expressed by
DLSR/65536 is greater than the delta between the timestamp when the DLSR packet
was received and the timestamp of the packet referred to by the LSR was
received. I apologize that I'm not sure how to generate this traffic to share
and I'm not at liberty to share the file that was sent to me.
Side-effects that I can think of:
Presumably, the minimum to report preference would have to be signed, as well.
The minimum to report preference appears to allow these values to be reported,
currently, which is actually desirable in some cases. It seems that the display
filter knows that the value is less than 0 (e.g. "rtcp.roundtrip-delay < 0"),
although, the == comparison seems to work on a positive number (e.g.
"rtcp.roundtrip-delay == 4294966423").
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
