[Winpcap-users] Very Strange behavior.
woodshop2300 at gmail.com
Thu May 7 18:29:55 PDT 2009
Hello All I'm having a very odd problem with a multithreaded app
( pthreads ) and winpcap.
I promise this is not a post about me crying because my program don't
work, thats not your problem honestly.
The situation looks like this.
I have 4 interfaces on a PC, hooked up to the interfaces is a network
device i'm testing.
What happens in the program is i open the 4 interfaces twice, so i
have a total of 8 handles.
I use one set of 4 handles for Tx and one for Rx.
To accomplish Rx i spawn 4 threads, 1 for each interface, each thread
sets its self as PTHREAD_CANCEL_ASYNCHRONOUS and then calls pcap_loop
never to return again.
The callback then feeds a common queue that i have thread guarded.
The basic execution is simple. Send from a Tx and Receive on a Rx.
This works fine.
The issue began when i started using lots of small data packets so the
time between Tx and Rx was very short.
I would reach a point in execution where i would send a frame Tx and
never get the frame Rx, after ruling out the device i'm testing having
my next assumption was then my threads got deadlocked some how. So i
Investigated with the Visual Studio 2008 debugger.
All 4 Rx threads were stuck on pcap_loop which was strange if i was
So i added a timeout on the receive, so if i didn't get something in
20sec after Tx the program would just die.
I ran that, and the program died after 20sec.. w00t. told me nothing.
So i wanted to check that the data on the interfaces Tx and Rx was
So i used the dumpcap.exe program ( winpcap ) to dump the Tx and Rx
interfaces i was having issues with during the time my App was running.
What i found makes no sense.
looking at the timestamps in the .pcap files the time between the Tx
time stamp and the Rx time stamp of the sudo missing packet is exactly
the timeout of my app. To me that makes 0 sense. How can my app,
( screwed or not ) mess with the pcap reception of 2 other completely
independent process on the PC?
So i did one final test. I used a 2nd PC to capture the Tx and Rx
lines in question through a Hardware TAP. the 20sec delay does NOT
exist on the wire, its completely inside the PC I'm using to test.
So my question is, can this be winpcap? could it be getting mixed up
somehow with so many handles?
I'm using the latest stable winpcap so that would be 4.0.2.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Winpcap-users