Re: Portable way to "block" on pcap_next_ex()

[Fernando Gont <fernando () gont com ar>]

Hi, Guy,

On 01/15/2012 07:28 PM, Guy Harris wrote:
> > The reason is that if I pcap_open_live() with a "to_ms" of 0, in
> > some systems pcap_next_ex() will remain blocked even if a packet is
> > received (i.e., it will wait for *many* packets).
>
> At least on systems with BPF, it'll block until the BPF buffer fills
> up, so it could wait indefinitely.

Yep, that's what I was experiencing on FreeBSD...



> On Linux, either the memory-mapped mechanism isn't being used, in
> which case each recvfrom() returns a single packet, with no timeout,
> or it is being used, in which case the timeout is done with an
> internal poll() call (if the pcap_t isn't in non-blocking mode), so
> you have a timeout that expires even if no packet has arrived.  I
> haven't looked at TPACKET_V3 in detail, but I suspect, from something
> I read, that it has a BPF-like timeout, i.e. the timer can expire if
> no packets are available.

Yep, that's what I see in my "tests".



> > (which is undesirable).
>
> Is that "undesirable" as in "I have to be able to handle
> pcap_next_ex() not returning a packet" (which may be annoying but can
> be dealt with) or "undesirable" as in "causes significant performance
> problems"?

For my current app, it's probably just "annoying" (although no big
deal). However, I was mostly concern about performance problems in other
applications. Put another way, if there's nothing that an app can do
without a packet being read, there's no reason for the app to be awaken.


> > Any other way of doing the same without relying on select()?
>
> No portable way.  Some systems (those with BPF) start the timer when
> you do a read(), so the timer goes off even if no packets have
> arrived.  Solaris's bufmod starts the timer when the first packet
> arrives.

So in the case of systems with BPF, if I used select() to check for
readability, my app would first block on select(), but then briefly
block an pcap_next_ex() for "to_ms" milliseconds....

In Solaris's case, that would depend on whether my app is actually run
before "to_ms" have elapsed since the reception of the first packet, right?


> BPF offers BIOCIMMEDIATE mode, which means that packets are *not*
> buffered (i.e., each read() returns a single packet) and there's no
> timeout.  The bufmod equivalent would be to set the read timeout to
> 0.  There's currently no API in libpcap to request that, so turning
> it on would currently have to be done in a platform-dependent
> fashion.

This would be an interesting thing to have. I'll add it to my queue.
(First will work on the pcap_geterr_code() thing).

As always, thanks so much for your incredible help!
-- 
Fernando Gont
e-mail: fernando () gont com ar || fgont () si6networks com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.