[prev in list] [next in list] [prev in thread] [next in thread]
List: winpcap-users
Subject: [Winpcap-users] Very Strange behavior.
From: Alex Anagnos <woodshop2300 () gmail ! com>
Date: 2009-05-08 1:29:55
Message-ID: C4046494-5B53-4652-BB60-E8BD0B82DFBF () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
[Attachment #5 (text/html)]
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; ">Hello All I'm having a very odd \
problem with a multithreaded app ( pthreads ) and \
winpcap.<div>I promise this is not a post about me crying because my \
program don't work, thats not your problem honestly.</div><div><br></div><div>The \
situation looks like this.</div><div>I have 4 interfaces on a PC, hooked up to the \
interfaces is a network device i'm testing.</div><div>What happens in the program is \
i open the 4 interfaces twice, so i have a total of 8 handles.</div><div>I use one \
set of 4 handles for Tx and one for Rx.</div><div>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.</div><div>The callback then feeds a \
common queue that i have thread guarded.</div><div>The basic execution is simple. \
Send from a Tx and Receive on a Rx. This works fine.</div><div>The \
issue began when i started using lots of small data packets so \
the time between Tx and Rx was very short.</div><div>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</div><div>my next assumption was then my \
threads got deadlocked some how. So i Investigated with the Visual Studio 2008 \
debugger.</div><div>All 4 Rx threads were stuck on pcap_loop which was strange if i \
was having deadlock.</div><div>So i added a timeout on the receive, so if i didn't \
get something in 20sec after Tx the program would just die.</div><div>I ran that, and \
the program died after 20sec.. w00t. told me nothing.</div><div>So i wanted to \
check that the data on the interfaces Tx and Rx was valid.</div><div>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.</div><div>What i found makes no \
sense.</div><div>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?</div><div>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.</div><div>So my \
question is, can this be winpcap? could it be getting mixed up somehow with so many \
handles?</div><div><br></div><div>I'm using the latest stable winpcap so that would \
be 4.0.2.</div><div><br></div><div><font class="Apple-style-span" size="4"><span \
class="Apple-style-span" style="font-size: 16px; \
"><b><br></b></span></font></div></body></html>
_______________________________________________
Winpcap-users mailing list
Winpcap-users@winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic