On Sat, Jul 25, 2009 at 5:29 AM, Guy Harris<g...@alum.mit.edu> 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.
Isnt this akin to a pipe becoming "readable" when the other end closes its filedescriptor. The pipe is readable but there is no data to read. What does ioctl(, FIONREAD, ) return when this happen? If your descriptor became readable by this ioctl returns 0 bytes available for reading, this could be used to detect this condition and abort the loop. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
