Ethereal-dev: Re: [Ethereal-dev] Problem with libpcap pcap_next() method

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Asra Baig <asrabaig@xxxxxxxxxxxxxxx>
Date: Mon, 22 Sep 2003 10:54:40 -0500 (CDT)
Do you know how can I download only editcap?

On Sat, 30 Aug 2003, Guy Harris wrote:

>
> On Friday, August 29, 2003, at 10:04 PM, Asra Baig wrote:
>
> > I am running a packet capture program that is using libpcap on Linux
> > 2.4.19.
>
> If the program isn't named "Ethereal" or "Tethereal", the right mailing
> list to ask for help with that program is the mailing list for the
> program, if it exists, or tcpdump-workers@xxxxxxxxxxx, if no mailing
> list exists for the program. as it's not an Ethereal issue.
>
> >  The pcap_next function just hangs no matter what timeout I give.
>
> To quote the current CVS version of the libpcap man page:
>
>         pcap_open_live() is used to obtain a packet capture descriptor
> to  look
>         at  packets on the network.  ... The read timeout is used to
> arrange that  the
>         read not necessarily return immediately when a packet is seen,
> but that
>         it wait for some amount of time to allow more packets to arrive
> and  to
>         read  multiple  packets  from  the OS kernel in one operation.
> Not all
>
> ^^^^^^^
>         platforms support a read timeout; on platforms  that  don't,
> the  read
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         timeout  is ignored.  A zero value for to_ms, on platforms that
> support
>         ^^^^^^^^^^^^^^^^^^^
>         a read timeout, will cause a read to wait forever to allow
> enough pack-
>         ets  to  arrive,  with  no  timeout. ...
>
> Linux is one of the platforms that does *NOT* support a read timeout.
>
> Note also that it says in the description of "pcap_dispatch()":
>
>         The  number  of  packets read is returned.  0 is returned if no
> packets
>         were read from a live capture (if, for  example,  they  were
> discarded
>         because  they  didn't  pass the packet filter, or if, on
> platforms that
>         support a read timeout that starts before any packets arrive,
> the time-
>         out  expires  before  any packets arrive, or if the file
> descriptor for
>         the capture device is in non-blocking mode and no packets  were
> avail-
>         able to be read) or if no more packets are available in a
> ``savefile.''
>         A return of -1 indicates  an  error  in  which  case
> pcap_perror()  or
>         pcap_geterr() may be used to display the error text.
>
>         NOTE: when reading a live capture, pcap_dispatch() will not
> necessarily
>         return when the read times out; on some  platforms,  the  read
> timeout
>         isn't supported, and, on other platforms, the timer doesn't
> start until
>         at least one packet arrives.  This means that the read  timeout
> should
>         NOT  be  used in, for example, an interactive application, to
> allow the
>         packet capture loop to ``poll'' for user input periodically, as
> there's
>         no  guarantee  that  pcap_dispatch()  will  return  after  the
> timeout
>         expires.
>
> "pcap_next()" is just a wrapper around "pcap_dispatch()".
>
> Linux is, as noted, a platform where the read timeout isn't supported.
>
> Solaris is a platform where the timer doesn't start until at least one
> packet arrives.
>
> The timeout *CANNOT* be portably used as a way of ensuring that
> "pcap_dispatch()" or "pcap_next()" won't block forever waiting for
> packets to arrive.
>