Guy Harris <[EMAIL PROTECTED]> writes:
> > 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.
What you describe serve as a timeout.
> 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.
Again, I'm not sure that I understand you here...
a read should not return if no packets have arrived.
A select() should be done before the read() instead to know if some data
arrive on the file descriptor within a specified timeout...
> 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.
Let say you implement this feature in pcap 0.6.3,
this just mean application wanting to use this pcap feature will
need pcap 0.6.3.
This is what happen with every library.
> 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
I don't see why this would not work in case you use select before reading.
Using it would make the ' return on timeout' behavior consistant for each
platform.
> 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.;
the to_ms argument of pcap_open_live is sufficient,
and should just set a timeval structure, used by the select().
> 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()".
A question about this point : is there a way to access the
fd used by pcap ?
> *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.
It just depend on what the caller application have to do.
I could use a similar method if there was a standard way to access pcap
fd... Unfortunelly, there is not.
--
Yoann Vandoorselaere | A woman is like your shadow; follow her, she flies; fly
MandrakeSoft | from her, she follows. -- Chamfort
-
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
