Wireshark-bugs: [Wireshark-bugs] [Bug 3535] New: Lucent/Ascend parser infinite loop while parsin
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3535
Summary: Lucent/Ascend parser infinite loop while parsing large
dumps
Product: Wireshark
Version: SVN
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: wireshark@xxxxxxxxxxxxxxx
Created an attachment (id=3117)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3117)
Brief capture to reproduce loop
Build Information:
Version 1.3.0 (SVN Rev 28718)
Copyright 1998-2009 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.16.1, with GLib 2.20.1, with libpcap 1.0.0, with libz
1.2.3.3, with POSIX capabilities (Linux), with libpcre 7.8, without SMI, with
c-ares 1.5.2, with Lua 5.1, without Python, with GnuTLS 2.6.6, with Gcrypt
1.4.4, with MIT Kerberos, without GeoIP, with PortAudio V19-devel (built Oct 12
2008), without AirPcap.
Running on Linux 2.6.28.7, with libpcap version 1.0.0, GnuTLS 2.6.6, Gcrypt
1.4.4.
Built using gcc 4.3.3.
--
Because Lucent/Ascend equipment will sometimes omit the hex dump for a packet
or send two headers followed by two hex dumps, Wireshark needs to be very
lenient when parsing a Lucent/Ascend trace. On a busy access server, a packet
like this is pretty likely to appear within a few minutes.
The attached tnt-loop.log (an excerpt from an actual capture) will send current
versions of Wireshark into an infinite loop, repeatedly seeking to and
reparsing the same position in the file. The attached patch
(wireshark-ascend-skipbad.diff) will make Wireshark quietly discard packets it
couldn't find the hex dump for. This fix isn't perfect, but it does make it
possible to decode the majority of a dump and use Wireshark to debug a problem.
I'm not sure what the best approach for fixing this is -- in the attached
example, the hex dumps are in reverse order vs. the headers, but I don't know
whether this is always the case. Maybe a truncated packet ("n bytes on wire, 0
bytes captured") should be logged for every packet where the hex dump can't be
found or reliably matched. Either way, the patch's behavior is better than the
current behavior.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
