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.
