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

[Guy Harris <guy () alum mit edu>]

On Jan 15, 2012, at 3:11 PM, Fernando Gont wrote:

> 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.

Well, presumably, yes, although I assume the folks at LBL had some rationale for starting the timer when the read() is 
done rather than when a packet arrives (starting the timer on a read() also complicates the implementation of 
select()/poll()/kqueues, as you have to start a timer when the application first expresses an interest in packets, even 
if it doesn't do so with a read(); as of Mac OS X 10.7, all the BSD-flavored OS now do that correctly - see below - but 
it took a while).

> 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....

On systems with BPF, if you use select() for readibility, what you get depends on what version of the OS you're running 
on. :-(

Here's the story, from the top-of-trunk version of the pcap_set_selectable_fd() man page:

       Note that in:

              FreeBSD prior to FreeBSD 4.6;

              NetBSD prior to NetBSD 3.0;

              OpenBSD prior to OpenBSD 2.4;

              Mac OS X prior to Mac OS X 10.7;

       select()   and   poll()   do   not   work  correctly  on  BPF  devices;
       pcap_get_selectable_fd() will return a file descriptor on most of those
       versions  (the  exceptions  being  FreeBSD  4.3  and 4.4), but a simple
       select() or poll() will not indicate that the  descriptor  is  readable
       until  a  full  buffer’s worth of packets is received, even if the read
       timeout expires before then.  To work around this, an application  that
       uses  select()  or  poll()  to  wait for packets to arrive must put the
       pcap_t in non‐blocking mode, and must  arrange  that  the  select()  or
       poll()  have a timeout less than or equal to the read timeout, and must
       try to read packets after that timeout expires, regardless  of  whether
       select() or poll() indicated that the file descriptor for the pcap_t is
       ready to be read or not.  (That workaround will not work in FreeBSD 4.3
       and  later; however, in FreeBSD 4.6 and later, select() and poll() work
       correctly on BPF devices, so the workaround isn’t  necessary,  although
       it does no harm.)

       Note  also that poll() doesn’t work on character special files, includ‐
       ing BPF devices, in Mac OS X 10.4 and 10.5, so, while select()  can  be
       used  on  the  descriptor  returned by pcap_get_selectable_fd(), poll()
       cannot be used on it those versions of Mac OS X.   Kqueues  also  don’t
       work  on  that  descriptor.   poll(),  but  not  kqueues,  work on that
       descriptor in Mac OS X releases prior to 10.4; poll() and kqueues  work
       on that descriptor in Mac OS X 10.6 and later.

and there's another item that needs to go in there, namely that in some versions of FreeBSD (I'd have to check which 
ones, but it should be fixed in FreeBSD 9) and in Mac OS X 10.6.x (fixed in 10.7), non-blocking reads from a BPF device 
won't pick up any packets until the store buffer fills up:

        http://www.FreeBSD.org/cgi/query-pr.cgi?pr=143855

If you have a system where select() works as it should, i.e.:

        FreeBSD 4.6 or later;

        NetBSD 3.0 or later;

        OpenBSD 2.4 or later;

        all versions of DragonFly BSD, as far as I know;

        Mac OS X 10.7 or later;

select() will block until either

        1) a bufferful of packets arrives

or

        2) the timer, started when the select() is done, expires, regardless of whether any packets are available to 
read.

I'd have to look at the BPF code in the OSes in question to see what happens when, after select() says packets are 
available to read, the read would return immediately or not.  Putting FDs on which you're using 
select()/poll()/epoll()/kqueues/etc. into non-blocking mode is generally a good idea; if you do that, then, modulo the 
non-blocking bug I mentioned earlier, pcap_next_ex() shouldn't block, although it might not return any packet.

> 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?

Your app can't be run before "to_ms" have elapsed since the reception of the first packet, because "the first packet" 
means "the first packet received after the getmsg() is done on the DLPI descriptor" - i.e., it's not the first packet 
received ever, it's the first packet received in a packet batch.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.