Currently, in "pcap_read()" in the current CVS version of
"pcap-linux.c", we do a "select()" to arrange that "pcap_dispatch()" not
block forever, waiting for a packet, if a non-zero read timeout was
specified in "pcap_open_live()".
This was done because some interactive applications may assume that the
read timeout will cause "pcap_dispatch()" to wait no more than the
specified amount of time, and therefore that if they've specified a
timeout, they can rely on it returning even if no packets have arrived,
so that they can then, for example, poll for user input.
However:
1) earlier versions of libpcap didn't do that on Linux;
2) Linux isn't the only platform on which there is no read
timeout in the kernel's packet capture mechanism;
3) on some systems where the kernel's packet capture mechanism
*does* have a read timeout - SunOS 5.x, for example, and
possibly earlier versions of SunOS - the timer doesn't appear
to start until at least one packe has arrived (that's the
behavior I saw on Solaris 7, i.e. SunOS 5.7, and the manual
page seems to indicate that this is the case).
I.e., applications cannot rely on the read timeout to expire when no
packets have arrived if they need that in order to keep the user
interface from hanging until packets arrive, unless those applications
are built only with versions of libpcap that do a "select()" like that
on all platforms that lack a read timeout in the kernel *and* do it on
SunOS 5.x (and possibly earlier versions of SunOS) and perhaps on
Digital UNIX as well (I don't know how its timeout works).
This means that, if they're to be able to work with the libpcap
libraries that are shipped with many Linux distributions, or to work on
Solaris, or to work on Irix (no timeout), or AIX (no timeout) or HP-UX
(no timeout), or a number of other platforms, they have to do the
"select()" themselves.
Ethereal has done so for a while on Linux; I just checked in a change to
make it do so on all non-BSD platforms. Etherape gets the file
descriptor with "pcap_fileno()" and adds it to the list of input file
descriptors in the GTK+ main loop with "gdk_input_add()" - I'll have to
see how this works on BSD, as the GTK+ main loop does a "poll()" (or a
"select()", but I think it's "poll()"), and at least on some BSDs
"select()" and "poll()" don't work well with the BPF read timeout.
We could, I guess, add a "select()" to all of the "pcap-XXX.c" files
that don't already have it and that are for OSes where the kernel
doesn't have a read timeout mechanism - and use it even on Solaris in
"pcap-dlpi.c".
However, applications would then have to be built with the latest and
greatest version of libpcap in order to depend on the read timeout
working.
I've already updated "pcap.3" to note that there is no guarantee that
"pcap_dispatch()" will return after the read timeout expires; I'd be
inclined to remove the "select()" from the Linux libpcap, to remove one
system call from the code path, and require applications to do the
"select()" themselves, either explicitly (as Ethereal currently does) or
implicitly (in, say, a toolkit's main loop, as Etherape currently does).
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
