Re: forcing pcap_loop() failures

[Eloy Paris <peloy () chapus net>]

Hi Guy,

On Thu, Oct 26, 2006 at 03:20:35AM -0700, Guy Harris wrote:

> > How would one notice that select() is not working correctly on a BPF
> > device on some of the BSDs?
>
> By compiling and running the attached program (compile with -lpcap)
> in one window, with "-i" used to select an interface (if the default
> one isn't active, e.g. on OS X if you're using AirPort rather than
> Ethernet, use "-i en1") and with "icmp" as a filter argument, and
> pinging some other host in another window.
>
> If you run it without the "-s" and "-t" flag, it just uses
> pcap_loop(); you should see it print "Saw a packet" shortly after a
> ping goes out or a ping reply arrives.
>
> If you run it with "-s" but without "-t", it uses select() without a
> timeout, and pcap_dispatch(); you probably won't see it print "Saw
> a packet" until enough pings go out or ping replies arrive, where
> "enough" is probably more than you'll see unless you let it run a
> really long time.
>
> If you run it with "-s" and "-t", it uses select() with a timeout
> (i.e., with the workaround), and pcap_dispatch(); you'll see it print
> "Saw a packet" shortly after a ping goes out or a ping reply arrives.

Okay, cool, I'll give this a try so I can finally understand this bug
;-)

> > You mention that recent versions of OS X are affected,
>
> Actually, all versions are affected by the problem with select(). (I
> said "current versions" not to imply that older versions didn't have
> the problem, but to indicate that, unlike some other BSD-flavored
> OSes, recent versions of Darwin/OS X do *not* have the bug fixed.)

Understood.

> > but I have an application that runs on OS X, that uses select() on a
> > BPF device, that doesn't use the workaround mentioned above (and in
> > pcap's man page), and I don't see any signs of broken behavior.
>
> How much traffic is your application getting? If enough shows up, the
> BPF kernel "store buffer" fills, which causes a select() on the BPF
> device to complete, so if it's seeing a lot of traffic, you won't see
> much of a delay before select() returns.

Actually my application doesn't normally get a lot of traffic because
most of the time I use BPF filters to look for very specific traffic.
However, I think the reason that I am not seeing any broken behavior is
because I use BIOCIMMEDIATE.

After I sent my message I recalled another exchange I had with you a
couple of months ago:

http://www.mail-archive.com/tcpdump-workers () lists tcpdump org/msg02498.html

There you mentioned "It works around the problem by getting rid of the
timeout, so that as soon as a packet arrives the packet is made
available, rather than the BPF device holding onto the packet until
either the timeout expires or the buffer fills up."

Guess that's the reason it's working fine for me. However, I wonder
if I really need to use BIOCIMMEDIATE. I mean, my application needs
to respond in real time to traffic received on the packet capture
descriptor. I remember that when I tested on FreeBSD (and some of the
other BSDs) unless I used BIOCIMMEDIATE I would no get packets right
away. tcpdump on FreeBSD, for example, doesn't seem to print packets in
real time; there's always a delay which seems to be the to_ms specified
in pcap_open_live() in tcpdump.c, which is 1,000 milliseconds. So it
seems like I really need to use BIOCIMMEDIATE and the cost is that no
buffering is done, more reads from the BPF device, and higher CPU, as
you mentioned in the message at the URL above.

On Linux everything works great without having to use any ioctl()'s, by
the way.

In my case I need to rely on the timeout provided by select() (the
user can change that timeout value) so I don't think I can use the
workaround you've explained and documented so many times because it
requires using the the timeout passed to pcap_open_live() as the timeout
for the select().

> > So, what are the symptoms of the broken behavior?
>
> See above.

Great, thanks for the info.

Cheers,

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