> I just updated to pcap 0.6.2, and it seem the behavior of
> the to_ms agument passed to pcap_open_live has changed.
>
> In my application, pcap_dispatch never return...
> here are some sample code :
>
> [...]
> dev->pd = pcap_open_live(dev->name, config.snaplen, 1, 1000, err);
The timeout value, on some platforms, does not serve as a "timeout" in
the sense that "pcap_dispatch()" will return after that amount of time,
regardless of whether any packets have arrived or not.
Linux, and platforms using DLPI (Solaris, HP-UX, probaby others), are in
that set of platforms; the timeout has no effect on Linux, IRIX, and
DLPI systems that don't support "bufmod" (e.g., HPUX), and, on Solaris,
will cause a non-full chunk of packets to be processed, but will *not*
cause the read done by libpcap to complete if *no* packets have arrived.
This dates back to the time when Solaris and/or Linux support was added
to libpcap; this is *not* new behavior. The LBL libpcap always worked
that way, and the tcpdump.org libpcap 0.5.x worked that way as well.
In 0.6, we fixed the manual page to describe reality; previous versions
of the man page falsely claimed that, when the read times out,
"pcap_dispatch()" is guaranteed to return.
Some versions of libpcap might have added timeout support on some or all
of those platforms, and, during development, the tcpdump.org libpcap had
code to do so, on Linux, at one point.
*However*, the problem with adding code to Just Make It Work is that you
then give any program that expects the timeout to Just Work, in the
sense that it expires even if no packets have arrived, a hidden
dependency on particular *versions* of libpcap.
I.e., if you happen to build and that program on a platform where
libpcap's timeout *doesn't* expire if no packets have arrived, the
program may well hang - and there's no good way of detecting, in a
configure script, whether the platform is such a platform, so as to
either
1) cause the program simply not to compile
or
2) supply a #define so that the program can, for example, put in
its own "select()" to work around the fact that the timeout
doesn't time out if no packets have arrived. (That's what
Ethereal does, but it just does it by assuming that any
platform other than BSD requires the select, so it'll do the
select even on, say, Linux systems where the native libpcap
uses its own "select()" to make the timeout work.)
So, if there really is a need for some programs to make the timeout
cause "pcap_dispatch()" to return even if no packets have arrived, then
the way to do that would be to
1) add a routine to libpcap that, when called on a "pcap_t *"
argument, puts it into a mode where libpcap won't wait
forever for packets to arrive - on some platforms, that
routine would be a no-op, but, on other platforms, it'd have
to set some state variable, etc.;
2) make sure *all* platforms on which that state variable has to
be used - not just Linux - use it;
3) have programs that require that behavior call that routine if
it's available, and, if it's not, either
1) fail to compile (as the program won't work correctly
on platforms where the routine isn't available)
or
2) work around the absence of the routine by, for
example, doing their own "select()".
*However*, I'm not sure when it'd be necessary for the timeout to cause
"pcap_dispatch()" to return.
If, for example, you have a GUI program that has to check for user input
while a packet capture is in progress, another way to do this might be
to hand the file descriptor for the "pcap_t" to the main loop of the GUI
toolkit as a descriptor on which to select, and put that descriptor into
non-blocking mode.
I have a version of Ethereal that does that, and it seems to work on BSD
(where we have to also set up a timeout in the GTK+ main loop, because
"select()" and "poll()" don't work correctly on BPF devices on a number
of BSD platforms), Linux, and Solaris. (I haven't checked in in yet, as
it doesn't yet work on Windows; I'm in the middle of making it work with
the new features added to WinPcap 2.1.)
-
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
