Guy Harris <[EMAIL PROTECTED]> writes:

> > > 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.

I was talking of an eventual select() call *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*.

I think saying that a library will have different behavior depending
of the architecture it is run on is just the proof the library is wrong.
Here you are talking of the read() behavior, different on many
architectures, but this problem can be avoided internaly to libpcap
(using, for exemple, the select() approach).

If I fix my program, 
I'll concider that I'm working arround a pcap library bug because
you should have an exact definition of how any pcap function behave,
independantly of the pcap architecture.

So either : 
   - you should remove the to_ms argument from pcap_open_live()

   or

   - you should make it work the way a timeout work, 
     independantly of the architecture.

> > >   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.

Again, the behavior you describe is documented no-where :

<man pcap>
pcap_fileno() returns the file descriptor  number  of  the ``savefile.''
</man pcap>


-- 
Yoann Vandoorselaere | "Programming is a race between programmers, who try and
MandrakeSoft         | make more and more idiot-proof software, and universe,
                     | which produces more and more remarkable idiots. Until
                     | now, universe leads the race"  -- R. Cook
-
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

Reply via email to