Re: select() regression in libpcap-devel?

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

On Jul 24, 2009, at 12:29 PM, Guy Harris wrote:

> On Jul 21, 2009, at 11:12 PM, Guy Harris wrote:
>
> > On Jun 23, 2009, at 7:34 PM, Mike Kershaw wrote:
> >
> > > (This now actually hits my error catcher where 100 fd highs in a row
> > > with no packets triggers a shutdown of the source, since  
> > > libpcap-1.0.0
> > > seems to not return errors in pcap_dispatch when a netdev is removed
> >
> > There does not appear to be a way for the memory-mapped interface  
> > to directly return such an error.
>
> And not only that, but my test program reports, on my Fedora 9  
> system (2.6.27.25-78.2.6.fc9.i686 kernel), that, if I unplug an  
> interface on which I'm capturing:
>
>         select() reports that the descriptor is readable;
>
>         there are *NO* packets to get from the memory-mapped buffer;
>
> 	select() does *not* report that there's an exceptional condition on  
> the descriptor;
>
> so the kernel and driver appear to be continuously reporting through  
> select() a condition *indistinguishable from "there's a packet  
> available"* even though no packets are available.

poll(), however, appears to report an exceptional condition on the  
descriptor, so that might let you discover a missing netdev.

Unfortunately, poll() doesn't work on character special files in OS X  
Tiger or Leopard; not only does that break applications using poll()  
on ttys (including the standard input and output if you're running on  
the terminal), it also breaks applications using poll() on BPF devices  
such as the ones opened by libpcap, so either "use poll() on Linux,  
select() elsewhere" or "use select() on OS X, poll() elsewhere" might  
be the right strategy.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.