http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1181
Summary: Delays in real-time packet capture
Product: Wireshark
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: richardv@xxxxxxxxxxxxx
Build Information:
wireshark 0.99.4 (SVN Rev 19460)
Copyright 1998-2006 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 without PortAudio, with GTK+ 2.8.18, with GLib 2.10.2,
with libpcap 0.9.4, with libz 1.2.3, with libpcre 6.4,
without UCD-SNMP or Net-SNMP, with ADNS, without Lua, with GnuTLS 1.4.0,
with Gcrypt 1.2.2, without Kerberos.
Running on Linux 2.6.16
with libpcap version 0.9.4 .
--
I posted this on the dev list; it went back and forth a couple of times, and I
don't really have the time or inclination to chase it much further.
Has anybody else noticed, that when capturing in realtime with a filter
that means that packets aren't captured very often, the last couple of
packets to be captured get 'stuck' until some more data comes along?
Sorry for the terrible explanation. It might be easier if I point to the
offending code:
In capture_loop.c, we have the following (simplified slightly):
> inpkts = capture_loop_dispatch(capture_opts, &ld, errmsg, sizeof(errmsg));
>
> /* Only update once a second (Win32: 500ms) so as not to overload slow displays */
> cur_time = TIME_GET();
> if (cur_time - upd_time > 0) {
> upd_time = cur_time;
>
> /* Let the parent process know. */
> if (inpkts_to_sync_pipe) {
> /* do sync here */
> libpcap_dump_flush(ld.pdh, NULL);
So the problem is that that if the packet count isn't flushed out just
after a packet is read, it then isn't written until another packet
arrives - which may not be for some time!
Options discussed to fix include:
1. #define MUST_DO_SELECT, so that capture_loop_dispatch uses a select() to
wait for packets to turn up, and put a second's timeout on the select().
Suffers from problems of non-portability.
2. Don't attempt to batch packets in dumpcap at all on OSes which don't
(properly) support it; and move the display update ratelimit to the wireshark -
might end up with a fair amount of data being sent over the pipe (though, since
this would be somewhat less than the actual traffic data, this shouldn't be a
problem).
3. Use select() with a timeout on Linux to emulate batching with a timeout.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.