On Thu, 2002-01-17 at 10:33, Guy Harris wrote: > On Thu, Jan 17, 2002 at 10:14:47AM +0100, Yoann Vandoorselaere wrote: > > > > 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(), > > The non-blocking mode is part of the workaround for the "poll()" bug - > the problem is that if you get a timeout from the select, and then try > to read from a BPF device, the read will block until either > > 1) the BPF timeout expires > > or > > 2) the buffer fills up > > and the BPF timeout starts when the *read* is done, so you'll still > block if the buffer isn't full.
but in this case (one interface), I'm not calling poll().. I directly call pcap loop with a cnt of -1... (And pcap-bpf.c in pcap 0.6.2 directly call read()) I do thi sin order to avoid the poll() bug, but it doesn't solve it (libc_r cause poll() to indirectly occur I think). > > but I suspect libc_r to make use of poll() when doing a read(). > > If you're using the thread library, I don't think the "select()" timeout > workaround will help; the thread library will expect "poll()" to work > correctly on BPF devices, so a thread blocking on a read from a BPF > device won't unblock until the buffer fills up. that's the problem... And aparantly it isn't safe to link a library (that does thread handling) against libc_r, then link a program to both normal libc + the library... -- Yoann Vandoorselaere http://www.prelude-ids.org
signature.asc
Description: This is a digitally signed message part
