Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] D-Bus support

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 26 Oct 2006 01:53:54 -0700
frederic heem wrote:

Do you mean that on Solaris, when a read blocks and no packet arrives, the read hangs forever ?

Yes.

The purpose of the timer on Solaris is *NOT* to ensure that reads always complete within a fixed period of time. The purpose of the timer is to ensure that if packets are arriving slowly, a packet won't remain queued up and unread indefinitely.

The pcap man page explicitly avoids making any claim that the timer will ensure that a read will complete within the timeout period.

I.e., any code that depends on the timer preventing a read on a pcap_t
from taking more than the specified amount of time is depending on
something that libpcap does not and will not guarantee (and the libpcap
man page explicitly indicates this).  Does your code depend on that?
Indeed, it depends on the fact that pcap_breakloop shall return in a time which ha to be predictable. See other bug report about this subject: https://sourceforge.net/tracker/index.php?func=detail&aid=1575387&group_id=53067&atid=469577

The problem there is that there's no way for a pcap_breakloop() call in one thread to "poke" the descriptor/handle associated with a pcap_t to force it to return (other than to close it, but pcap_breakloop() is intended to leave the pcap_t usable; a reopen of the device, followed by a replacement of the descriptor in the pcap_t with the new descriptor, followed by a close of the original device, might achieve that, although that'd have to be done carefully to ensure it's thread-safe).

If you call pcap_breakloop() within a signal handler, and the signal is delivered to the thread reading from the descriptor, and the signal is set to interrupt system calls, pcap_breakloop() will work.