Bug ID |
9571
|
Summary |
Wireshark stops showing new packets but dumpcap keeps writing them to the temp file
|
Classification |
Unclassified
|
Product |
Wireshark
|
Version |
1.10.3
|
Hardware |
x86
|
OS |
Linux (other)
|
Status |
UNCONFIRMED
|
Severity |
Normal
|
Priority |
Low
|
Component |
Wireshark
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Created attachment 12331 [details]
patch
Build Information:
TShark 1.10.3 (SVN Rev Unknown from unknown)
Copyright 1998-2013 Gerald Combs <[email protected]> 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 (32-bit) with GLib 2.24.2, with libpcap, with libz 1.2.3.4, with POSIX
capabilities (Linux), without libnl, with SMI 0.4.8, with c-ares 1.7.3, with
Lua
5.1, without Python, with GnuTLS 2.8.6, with Gcrypt 1.4.5, with MIT Kerberos,
with GeoIP.
Running on Linux 2.6.32-5-686, with locale en_US.UTF-8, with libpcap version
1.1.1, with libz 1.2.3.4.
Built using gcc 4.4.5.
--
Sometimes, even after running for days, wireshark/tshark stop showing new
packets. Dumpcap still captures them and writes to the buffer file however it
stops notifying the parent process. This can be seen in an strace, dumpcap now
writes to the buffer file in 4K chunks and there are no writes to stderr.
It seems this is due to an overflow in capture_loop_start()'s throttling logic:
gettimeofday(&cur_time, NULL);
if ((cur_time.tv_sec * 1000000 + cur_time.tv_usec) >
(upd_time.tv_sec * 1000000 + upd_time.tv_usec + DUMPCAP_UPD_TIME*1000)) {
Using 1000000ULL instead of 1000000 fixes this problem for us.
You are receiving this mail because:
- You are watching all bug changes.