[Winpcap-users] Very Strange behavior.

[Alex Anagnos]

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  
an error
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  
having deadlock.
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  
valid.
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...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20090507/1cc6e466/attachment.htm