[Winpcap-users] Re: breaking out of a pcap_next_ex() loop

[Gianluca Varenni]

----- Original Message ----- 
From: "Guy Harris" <guy at alum.mit.edu>
To: <winpcap-users at winpcap.org>
Sent: Monday, May 15, 2006 11:23 AM
Subject: Re: [Winpcap-users] Re: breaking out of a pcap_next_ex() loop


> Gianluca Varenni wrote:
>
>> The most important problem is that it doesn't actually stop the capture 
>> immediately: if simply exits the capture loop *when* the read timeout 
>> occurs or at the first reception of a packet (whatever comes first). If 
>> you put a long timeout (say 10 seconds) and you don't receive packets, 
>> pcap_next_ex/pcap_loop/pcap_dispatch will return after up to 10 seconds.
>
> It was originally added for use in signal handler routines on UNIX; if a 
> signal occurs while libpcap is blocked waiting for packets to arrive, the 
> system call on which it's blocked with return an EINTR error, which will 
> break out of the packet read/receive.
>
> However:
>
> 1) that doesn't happen on Windows;
>
> 2) that doesn't, as far as I know, help on UNIX if the signal is delivered 
> to a thread other than the one blocked in libpcap.
>
> 1) could be handled if there were a packet.dll call that poked the driver 
> (with a new ioctl or something such as that) to cause any blocked read on 
> a particular open device to return immediately with an error indication. 
> 2) might require a similar facility in the packet capture mechanisms in 
> various UN*Xes.

Well, on Windows it's not so difficult, as the read is blocked at user level 
(in PacketReceivePacket) and not at kernel level. What we just need to do 
(if we want to add such a feature) is to add a Packet function that just 
sets the read event, thus awakening any thread waiting on a 
PacketReceivePacket. Do we really need/want that feature?

Have a nice day
GV



> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users