Wireshark-bugs: [Wireshark-bugs] [Bug 2522] New: Support all 256 interleaved RTSP channels
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2522
Summary: Support all 256 interleaved RTSP channels
Product: Wireshark
Version: 0.99.7
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Minor
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: pkj@xxxxxxxx
Created an attachment (id=1774)
--> (http://bugs.wireshark.org/bugzilla/attachment.cgi?id=1774)
Support all 256 interleaved RTSP channels
Build Information:
wireshark 0.99.7
Copyright 1998-2007 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.16.1, with libpcap 0.9.4, with libz
1.2.3, with libpcre 6.6, without SMI, without ADNS, without Lua, with GnuTLS
1.4.1, with Gcrypt 1.2.3, with MIT Kerberos, without PortAudio, without
AirPcap.
Running on Linux 2.6.20-1.2962.fc6, with libpcap version 0.9.4.
Built using gcc 4.1.2 20070626 (Red Hat 4.1.2-13).
--
For some reason only the first eight interleaved RTSP channels are supported by
epan/dissectors/packet-rtsp.c. This is a problem for us as one of our servers
use the channel numbers in a round robin fashion and will thus use all 256
channels. The limit on eight channels will also make the behaviour of Wireshark
seem somewhat random as it will sometimes dissect a stream and sometimes not
without any apparent reason for the behaviour (unless you look at the source
code)...
My guess at the limit on eight channels is to reduce the memory footprint, but
memory is cheap these days so I hardly believe this to be a real problem.
Anyway, here is a patch to rectify this situation.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
