https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7436
Summary: Single packet capture takes 10 CPU-seconds to decode
(in dissect_rpc_?)
Product: Wireshark
Version: 1.8.0
Platform: x86
OS/Version: All
Status: NEW
Severity: Major
Priority: Low
Component: Dissection engine (libwireshark)
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: wireshark-bugs@xxxxxxxxxxx
Build Information:
Version 1.8.0 (SVN Rev 43431 from /trunk-1.8)
Compiled (32-bit) with GTK+ 2.24.10, with Cairo 1.10.2, with Pango 1.30.0, with
GLib 2.32.2, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS
2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio
V19-devel (built Jun 21 2012), with AirPcap.
Running on Windows XP Service Pack 3, build 2600, without WinPcap, GnuTLS
2.12.18, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 10.0 build 40219
--
Looking at a large (> 500MB) capture of NFS traffic, loading the file into
Wireshark on Windows was taking aaaages.
The cause appears to be that certain packets in the capture take 10 cpu-seconds
to process. Narrowing down the issue for this bug report, I can reproduce the
problem with a single packet.
This issue is observed on both Wireshark 1.8.0 (SVN Rev 43431) on Windows, and
TShark 1.0.15 shipping with RHEL 5.
Steps to reproduce:
- Take the 350-byte tcpdump file attached
- Load into Wireshark, or process with "tshark -r trim-lone-packet-obfuscated"
What happened:
- High CPU observed during loading
What was expected:
- Single packet should not take 10 CPU-seconds to process
Workaround:
- Using tshark -V -r ... somehow avoids the expensive codepath, and completes
in 0.4 seconds
Capture notes / privacy:
The capture file was created with tcpdump, trimmed with editcap, and obfuscated
with Python file.seek() / file.write() calls. The obfuscated fields are
eth.dst, eth.src, ip.src, ip.dst, rpc.auth.machinename, nfs.pathname.component.
These obfuscations cause the IP header checksum and TCP checksum to fail, but
this has no effect on the overall problem. I could probably provide the
unedited packet if the problem can't be reproduced using the obfuscated one.
Backtrace:
During the 10-second window in tshark, I obtained the attached stack trace.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.