On Wed, Jan 03, 2001 at 09:01:38AM -0500, [EMAIL PROTECTED] wrote:
> As I skimmed through the updated pcap-linux.c, I wonder what happens
> there:
>
> By removing select() we are not longer able to specify a timeout.
You never were able to specify a timeout in libpcap; the so-called "read
timeout" in libpcap has never been guaranteed to be a timeout (except
perhaps when libpcap ran only with BPF, but I suspect that, back then,
there *was* no libpcap, that code was just part of tcpdump).
It is, in fact, not a timeout, in the sense that you are guaranteed that
a "pcap_dispatch()" will return within some period of time regardless of
whether any packets have arrived, on:
Solaris (because the kernel's read timer for the "bufmod"
streams module doesn't expire if no packets have arrived);
HP-UX and AIX (because there's no "bufmod" module that comes
with the OS);
Irix (because there's no kernel timer).
So any application that uses the timeout as a way of being sure it can
periodically poll for user input is broken. For example, I just changed
Ethereal so that it does its own "select()" on *all* platforms other
than BSD, not just on Linux, because, on my low-traffic home "network"
(whose two nodes are my home machine and my ADSL modem), Ethereal
neither updated the capture dialog box nor responded to user input until
I did a "ping" to force some packet onto the wire.
Furthermore, even if we changed *all* of those to have their own select
to implement the timeout, applications would still have to do their own
"select()" unless they were guaranteed to be used only with the new
version of libpcap.
> The recvfrom() call on which all pcap_read_XYZ() pcap_next() etc
> are based on, is a slow system call now, which means it can block forever.
Correct. If you don't want to block forever in a libpcap-based
application, you have to do your own "select()", as has always been the
case.
If it's OK if the application blocks forever - as is the case with, for
example, tcpdump and Tethereal - no "select()" is necessary.
If you do your own "select()" as Ethereal does, your application works
regardless of whether libpcap does it for you - and if libpcap does it
for you as well, that's an extra system call.
If you do your own select as Etherape does - i.e., if you add the file
descriptor for the libpcap device to the list of file descriptors on
which your UI's main loop selects:
your application works regardless of whether libpcap does it for
you;
your application responds more quickly to user input because
it's blocked on a "select()" (or "poll()") that includes the
connection to, say, your X server rather than being blocked on a
"select()" in libpcap which wakes up only after a timeout.
(I have a version of Ethereal that does that; unfortunately, that
doesn't work on Windows, as Microsoft didn't make
"WaitForMultipleObjects()" work on devices, the way "select()" does, so
I have to make it continue to use the old timeout stuff on Windows until
such time as WinPcap's driver can be made to provide a synchronization
object on which you *can* do a "WaitForMultipleObjects()".)
In either of those cases, you could do a "select()" on more than one
libpcap device, and thus capture traffic from multiple devices (the
"any" device works only on Linux - and, even on Linux, doesn't let you
see the real link-layer headers).
> Thus, checking for EAGAIN error is useless as well.
Not true. The file descriptor could be put into non-blocking mode by
the application; that's what the version of Ethereal that uses the GTK+
main loop's "poll()" does.
> I don't see the idea behind this now :) Sorry, but I haven't read
> the list much during newyear.
The reason why I removed the "select()" was mentioned in earlier mail,
but the above summarizes it:
there never was any guarantee that the timeout was a timeout
that would cause "pcap_dispatch()" to return within a fixed
period of time regardless of whether any packets arrived, the
claim to that effect in the man page nonwithstanding (I fixed
the man page to reflect reality);
even if we threw in a pile of "select()"s to provide such a
guarantee, applications would still have to do their own
"select()"s unless they required the latest libpcap (and they'd
have to check the version number of the libpcap library to
ensure that; from my experience with Ethereal, I can almost
guarantee that *somebody* would build Ethereal or some other
application with the wrong library and then complain that it
hung, causing a long sequence of e-mails in which we finally say
"OK, you'll have to install a new version of libpcap and rebuild
the application" - which wouldn't help if they didn't build it
but just installed a binary - and that this would happen over
and over again);
applications such as tcpdump and Tethereal don't care whether
the timeout expires regardless of whether any packets have
arrived;
applications such as Ethereal, Etherape, etc. would arguably
work better if they used the GUI toolkit's main loop's
"select()" or "poll()".
-
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
