> I've been trying to find a workaround against this BSD bug in my
> project. There is two basic case :
>
> 1) listening on several interface
> 2) listening on one interface.
>
> I used to call the same code path for both, polling my set of descriptor
> then calling pcap_loop() with a cnt of 1 when something was available
> for reading.
>
> Unfortunaly, it doesn't work on BSD (you get packet by burst because it
> is waiting for the buffer to be filled before returning).
The way I handle that problem in a not-yet-checked-in change to Ethereal
(not yet checked in because, to work on Win32, it will require a
still-under-development version of WinPcap, because I need to make
sure that non-blocking mode and "select()"/"poll()" work on pcap devices
on MacOS X, and because I need to make sure it'll work with those Linux
libpcaps that support memory-mapped access to PF_PACKET sockets) is to
1) put the pcap device in non-blocking mode;
2) set a timeout handler in the GTK+ main loop (as well as
posting the file descriptor on UNIX, and the event on Win32,
as an input source in that main loop);
3) have the timeout handler attempt to read packets from the
pcap device.
For multiple devices, the handler would have to attempt to read packets
from *all* the pcap devices.
> I tryed a simple workaround, when there is only one interface to listen
> on (most of the case), which is to call pcap_loop() with a cnt of -1.
>
> Someone tested the workaround on FreeBSD 5.0, and it seem we're still
> getting burst of packet.
Did you put the devices into non-blocking mode?
BTW, FreeBSD 5.0-current *should* have a fix to the "select()" bug, from
some mail I've seen; if, on an up-to-date 5.0-current system, "select()"
or "poll()" on a BPF device doesn't return when the timeout expires,
that is, I think, a bug, and should be reported to the FreeBSD
developers.
-
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
