> But are you suggesting to use a select call on the
> pcap capture itself?
Yes.
> I was under the impression that
> this was not possible in Linux.
It is possible on most if not all flavors of UNIX, including Linux.
(It's not possible to do so with the same code on Windows, but there's
an API in WinPcap to return a handle for an "event" that you can hand to
the various WaitFor calls.)
The select should have a timeout, and if the timeout expires the
application should still try to read from the capture device, in order
to work around BSD bugs that prevent "select()" from working with BPF
devices on many BSDs. (You should therefore put the file descriptor
into non-blocking mode.)
> I dont see any file
> descriptors in the Public API for libpcap
The current CVS and 0.7 beta version of the libpcap man page says
SYNOPSIS
...
int pcap_fileno(pcap_t *p)
...
pcap_fileno() returns the file descriptor number from which
captured packets are read, if a network device was opened
with pcap_open_live(), or -1, if a ``savefile'' was opened
with pcap_open_offline().
Earlier versions of the man page said
pcap_fileno() returns the file descriptor number of the
``savefile.''
but that was erroneous.
> If that
> is the case couldn't libpcap be able to add the
> functionality of returning out of the pcap_dispatch in
> the absence of packets, by doing a non blocking select
> call on that fd?
It could, but that's the job of the application, which may well need to
do a select on *more than one* descriptor.
-
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
