In message <[EMAIL PROTECTED]>, Guy Harris writes:
>On Mon, Dec 18, 2000 at 07:58:04AM +1100, Darren Reed wrote:
>> Haven't we already fixed this one ?
>>
>> Darren
>>
>> ----- Forwarded message from John Polstra -----
>>
>> Message-Id: <[EMAIL PROTECTED]>
>> From: John Polstra <[EMAIL PROTECTED]>
>> Date: Sun, 17 Dec 2000 12:50:23 -0800 (PST)
>> Subject: cvs commit: src/sys/net bpf.c
>> X-FreeBSD-CVS-Branch: HEAD
>>
>> jdp 2000/12/17 12:50:23 PST
>>
>> Modified files:
>> sys/net bpf.c
>> Log:
>> Fix bug: a read() on a bpf device which was in non-blocking mode
>> and had no data available returned 0. Now it returns -1 with errno
>> set to EWOULDBLOCK (== EAGAIN) as it should. This fix makes the bpf
>> device usable in threaded programs.
>>
>> Reviewed by: bde
>>
>> Revision Changes Path
>> 1.72 +7 -6 src/sys/net/bpf.c
>
>Who are "we"?
>
>
>So if "we" refers to tcpdump.org, we can't fix this one; it requires a
>kernel change.
>
>(The current top-of-tree NetBSD "sys/net/bpf.c" still appears to have
>this problem. The current top-of-tree OpenBSD looks as if it fixes
>this.)
i'm currently working on the next generation bpf for openbsd...
i've got a first version which i'm testing right now. The mods
only deal with the data recording portions of bpf, not any
filtering code.
>The current top-of-tree *Free*BSD may still have *another* problem,
>which is that a "select()" on a BPF device won't pay any attention to
>the read timeout on the BPF device; instead, it'll block until the store
>buffer fills.
>
>This is OpenBSD PR 1459:
>
> "/sys/net/bpf.c when accessed via libpcap with the select system
> call with timeout does not flush the buffers (if they aren't
> full) when the timeout occurs. There is code there that is
> supposed to do this (or something like it) but it doesn't work
> in this particular case. This doesn't affect tcpdump because it
> appears to be running in immediate mode (which is probably
> performance limiting but does work)."
yes, the nfr/bpf mods which used to be in the bpf, before it 2.5's
bpf was upgraded included fixes for that... but there was still
a bug where if no data arrived, the packet's would be freed.
mts
-
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