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.
