From owner-freebsd-stable Fri Jul 6 14:32: 7 2001 Delivered-To: freebsd-stable@freebsd.org Received: from warez.scriptkiddie.org (uswest-dsl-142-38.cortland.com [209.162.142.38]) by hub.freebsd.org (Postfix) with ESMTP id D2CDE37B401 for ; Fri, 6 Jul 2001 14:31:58 -0700 (PDT) (envelope-from lamont@scriptkiddie.org) Received: from warez.scriptkiddie.org (warez.scriptkiddie.org [209.162.142.38]) by warez.scriptkiddie.org (Postfix) with ESMTP id 6631C62D03; Fri, 6 Jul 2001 14:31:58 -0700 (PDT) Date: Fri, 6 Jul 2001 14:31:58 -0700 (PDT) From: Lamont Granquist To: John Polstra Cc: , Subject: Re: bpf/libpcap and pthreads In-Reply-To: <20010706133246.W95591-100000@warez.scriptkiddie.org> Message-ID: <20010706142008.G95641-100000@warez.scriptkiddie.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG sorry for the reply to the reply to the reply... freebsd has a userspace pthreads implementation, correct? so, what it appears to be doing is calling bpfread() with IO_NDELAY and bpfread() is returning EWOULDBLOCK. it then goes into poll() and sleeps waiting for input which doesn't happen until catchpacket() fills up the storage buffers and calls bpf_wakeup(). so, one hack i could do would be to put it into immediate mode, so that for every packet it calls bpf_wakeup(). to fix this and preserve the timeout for buffering in kernel space you'd have to have catchpacket() know that someone has been sleeping on the descriptor for a time that exceeded the read timeout and calls bpf_wakeup() -- except that even if you don't recieve a packet you still need to wake the thread up when it exceeds the read timeout... hmmm... right, i'm over my head... On Fri, 6 Jul 2001, Lamont Granquist wrote: > okay, i did some more debugging. it looks like it is correctly capturing > all the packets. the difference comes in that when its linked with > -pthreads it calls bpfread() and then goes into poll(). it then hangs in > poll() for a good long time. it does not hang in bpfpoll(). turns out > that i wasn't waiting long enough earlier and that it does eventually > timeout and i get what looks like expected output. > > i'll keep playing with it and see what else i can find... > > On Fri, 6 Jul 2001, Lamont Granquist wrote: > > On Fri, 6 Jul 2001, John Polstra wrote: > > > Yes, I did merge the fix into -stable January 5, 2001. It is in > > > "src/sys/net/bpf.c" revision 1.59.2.5. > > > > * $FreeBSD: src/sys/net/bpf.c,v 1.59.2.5 2001/01/05 04:49:09 jdp Exp $ > > > > is what i'm using. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message