Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 5313] New: follow tcp stream takes extremely long to displ

Date: Tue, 19 Oct 2010 04:42:36 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5313

           Summary: follow tcp stream takes extremely long to display on
                    long tcp sessions
           Product: Wireshark
           Version: 1.4.1
          Platform: x86
        OS/Version: Windows 7
            Status: NEW
          Severity: Major
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: disorganizer@xxxxxxx


Build Information:
Version 1.4.1 (SVN Rev 34476 from /trunk-1.4)

Copyright 1998-2010 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.6, (32-bit) with GLib 2.22.4, with WinPcap (version
unknown), with libz 1.2.3, without POSIX capabilities, without libpcre, with
SMI
0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.8.5, with
Gcrypt 1.4.5, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built
Oct
11 2010), with AirPcap.

Running on 32-bit Windows 7, build 7600, with WinPcap version 4.1.2 (packet.dll
version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008),
GnuTLS 2.8.5, Gcrypt 1.4.5, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
i have a 9mb tracefile of a telnet session transmitting binary data between a
client and a server.

when using the "follow tcp stream" feature on this tcp flow, the filtering
works fine.

after the filter was applied, when normally wireshark would display the
contents of the stream, wireshark does not react any more and takes more and
the wireshark process takes more and more memory from the system.

i waited for 2 hours on my 2gb i5-540 system and then stopped the process
without having a result.

when shortening the tracefile drastically (around 10000packets instead 80000)
it works (the output dump is around 300kbytes then).

i guess that the "text editor" used to display the contents of the stream is
not capable of displaying files so long without any rc/lf?

if yes, maybe a feature that could help would be to be able to directly export
the content of a tcp stream into a textfile (like you would when displaying it)
without displaying it.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.