ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 1181] Delays in real-time packet capture

Date: Fri, 24 Aug 2007 15:39:39 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1181


richardv@xxxxxxxxxxxxx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




------- Comment #11 from richardv@xxxxxxxxxxxxx  2007-08-24 15:39 GMT -------
Right. This one just got to be too annoying for me to ignore any longer.

(In reply to comment #7)
> 2. Fix wireshark not to update the GUI on every update from dumpcap; then don't
> bother with packet-batching at all in dumpcap.

It struck me that, as well as stopping wireshark updating the GUI for every
packet, batching them up also avoids quite so much context-switching between
the dumpcap and wireshark processes - which might be quite beneficial in a busy
capture.

Hence:

> 1. Use appropriate "configure" magic to allow us to detect a system on which
> it's possible to select() on the capture fd and implement a timeout for systems
> which don't properly support packet batching.

The problem here really is just that pcap_dispatch() on linux ignores the
timeout set in pcap_live_open(). We know that doing select() on the capture fd
in linux is fine, so I've just modified capture_loop.h to force MUST_DO_SELECT
on linux.

Hence, I believe this to be fixed as of revision 22639.


-- 
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.