On Wed, 2002-01-16 at 20:41, Guy Harris wrote: > > 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.
This is not an ideal fix in my case (NIDS)... Because there is time constrain for certain attack detection... And we wouldn't get the packet by the time it was captured. > > 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? I didn't, because AFAIK, the bug is concerning poll() and not read(), but I suspect libc_r to make use of poll() when doing a read(). I simply modified my code so that when capturing from a single interface (most of the case), we won't have to use poll(). > 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. Krzysztof ? -- Yoann Vandoorselaere http://www.prelude-ids.org
signature.asc
Description: This is a digitally signed message part
