> > 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.
Whether a read will return if no packets have arrived is
platform-dependent.
Applications using libpcap cannot rely on it returning if the timeout
expires and no packets have arrived.
Applications using libpcap also cannot rely on it *not* returning 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...
That's the only way you can guarantee that the program will not block
forever waiting for data to arrive.
> > *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.
Yes, but it will cause a large amount of support pain if the feature is
implemented in such a way that the program will compile and link with
earlier versions of the library, as the program will, if built on a
system with an earlier library - or, if the program is dynamically
linked with libpcap, even if the program is built on a system with a
version of the library where the timeout causes a read to return if the
timeout expires and no packets have arrived, but is *run* on a system
with an older version of libpcap - just hang, rather than failing in
some obvious way.
> > 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.
Yes, it'll work if you use select before reading...
...*which was the very thing I suggested that you do*.
But if you use select before reading, *you don't have to change
libpcap*.
> > 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().
To which "select()" are you referring? There is no "select()" in
libpcap.
The reason for adding the routine is to make sure that a program that
requires that the timeout cause a read to return even if no packets have
arrived *will not compile if you try to link it with a version of
libpcap where the read might not return until at least one packet has
arrived*, and *will not run with a libpcap shared library where the read
might not return until at least one packet has arrived*.
> > 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 ?
"pcap_fileno()". See the "pcap(3)" man page.
(This won't work on WinPcap, but neither will "select()"; you'd have to
do things differently on Windows anyway, so the fact that you call
"pcap_getevent()", in WinPcap 2.1, rather than "pcap_fileno()" on
Windows doesn't add a new portability problem.)
> > 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.
Yes, there is - "pcap_fileno()".
-
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
