I added it; I forget which release I added it in.
The problem is that the FD for the capture is not always selectable -
for example, the DAG driver doesn't support select(). That's why I
added it; it could well return -1, which means "sorry, you can't do
select on this".
I've added notes on that to the bug.
Windows does not implement it as does not even have selectable fds or
at least the one select() in winsock does not work on FDs so for
WinPcap another approach should be taken (Gianluca?)
I *should* be possible to get the handles for the capture streams with
pcap_getevent(), and WaitForMultipleEvents().
I don't know whether that works with AirPcap adapters, however.
It works (even with AirPcap adapters), with a caveat. The handle doesn't get
signalled immediately. It gets signalled when at least mintocopy bytes have
been stored in the WinPcap kernel buffer. By default mintocopy is 16k, so if
you receive less than 16k packets, the event never gets signalled. You can
use WaitForSingleObject/WaitForMultipleObjects, *but* you need to use a
timeout to avoid a deadlock if less than mintocopy bytes are received.
Have a nice day
I did not notice the load-peak while playing with it but I believe I
should have felt it in my very slow PPC mac... do pcap_dispatch works
differently in linux and bsds? (Guy?)
The main difference is that Linux, unless you're using the memory-mapped
capture mechanism (supported by the under-development libpcap 1.0), you
get one packet per recvfrom() call, while in OS X and *BSD, BPF will
buffer up packets until the buffer fills up or the timeout expires, so
you can get multiple packets per read().
Wireshark-dev mailing list