https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1752
--- Comment #6 from disorganizer@xxxxxxx 2010-10-20 01:02:30 PDT ---
I have the same issue with the most up to date version of wireshark on windows
7
Version Details:
Build Information:
Version 1.4.1 (SVN Rev 34476 from /trunk-1.4)
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
I posted the details on bug 5313, here a summary of them:
Setup:
A 9mb tracefile of a telnet session containing a binary data transfer between
client and host (so no lines).
When doing a follow tcp stream on this telnet session on my i5-540 2gb system
with windows 7 it takes ages to display the content in a windows.
when after several hours the window finally comes up scrolling is extremely
slow (also several hours on each move).
When reducing the # of packets (aka the file content) everything works fine.
I guess that the uses "text-editor" to display the content does not correctly
handle large files.
Maybe 2 ideas to solve this (at least temporarily):
1) configurable external text editor
2) direct export of a tcp stream as textfile without first 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.
