Delays in packet capture on Windows with named pipes

This issue was migrated from bug 2200 in our old bug tracker.

Original bug information:

Reporter: Benjamin Tse
Status: RESOLVED DUPLICATE
Product: Wireshark
Component: GTK+ UI
OS: Windows XP
Platform: x86
Version: 0.99.6

Attachments:

ws2200.patch: Proposed patch for Bug 2200

Duplicate of issue #1759 (closed)

💬 Benjamin Tse said:

Build Information: Version 0.99.6a (SVN Rev 22276)

Copyright 1998-2007 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 with GTK+ 2.10.12, with GLib 2.12.12, with WinPcap (version unknown), with libz 1.2.3, with libpcre 6.4, with Net-SNMP 5.4, with ADNS, with Lua 5.1, with GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio PortAudio V19-devel, with AirPcap.

Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.1 beta (packet.dll version 4.1.0.902), based on libpcap version 0.9.6 branch, with AirPcap 3.0.0 build 954.

Built using Microsoft Visual C++ 6.0 build 8804

Bug 1181 still happens on Windows machines when capturing from a named pipe.

I've created a new bug rather than reopening 1181 as the scope is constrained somewhat more.

Basically, when capturing from a named pipe the wireshark display lags by one packet. This is especially frustrating when the packets arrive at low rates.

tshark is fine. But the packet count in dumpcap also lags by one.

Looking at the code, the problem appears to be in cap_pipe_select(). It attempts to use WaitForSingleObject() on the named pipe but AFAICT this never blocks.

I've attached a diff for some code that fixes the issue for me. The semantics of overlapped IO in Win32 is quite different from the select/read model - hence the other changes!

I've tested this fix on WinXP, 2k server and 2003 server. I've also checked that my changes compile on a Freespire box that I have lying around.

added oswindows uigtk version0.x labels

💬 Benjamin Tse said:

Created attachment 1391 Proposed patch for Bug #2200 (closed)

Patch to use overlapped IO on Win32 to prevent capture from a named pipe lagging by one packet.

The overlapped IO effectively replaces the select() call that Unix and non-named pipe capture uses.

💬 Stephen Fisher said:

Comment on attachment 1391 Proposed patch for Bug #2200 (closed)

Mark for review

💬 Benjamin Tse said:

*** Bug #1815 (closed) has been marked as a duplicate of this bug. ***

💬 Gerald Combs said:

Comment on attachment 1391 Proposed patch for Bug #2200 (closed)

Checked in in r28452. The changes had to be applied by hand to dumpcap.c, which is where that code now lives. Thanks!

💬 Gerald Combs said:

This patch seems to cause more problems than it fixes. When reading from stdin here, zeroes seem to be inserted in random places in the file. Unfortunately I've had to back it out in r28852.

A better approach might be to move the read code to a separate thread where it can block without affecting the main thread.

💬 Gerald Combs said:

*** This bug has been marked as a duplicate of bug #1759 (closed) ***

closed