In message <[EMAIL PROTECTED]>, Guy Harris writes:
>On Tue, Dec 12, 2000 at 02:45:29PM +0100, Thomas Walpuski wrote:
>> 2. why does pcap_next() (and pcap_loop() too) doesn't return the
>> first packet immedeadly, when it was sent? instead i have to send a
>> couple (up to 400) packets, before it returns the first packet.
>
>(I'm assuming, from your signature line, that you're using OpenBSD.)
>
>"pcap_open_live()" has a "to_ms" argument, which sets the "read
>timeout"; the FreeBSD BPF man page says:
>
> ...
>
> BIOCSRTIMEOUT
>
> BIOCGRTIMEOUT (struct timeval) Set or get the read timeout parameter.
> The argument specifies the length of time to wait before
> timing out on a read request. This parameter is initial-
> ized to zero by open(2), indicating no timeout.
>
> ...
>
> BIOCIMMEDIATE (u_int) Enable or disable ``immediate mode'', based on the
> truth value of the argument. When immediate mode is en-
> abled, reads return immediately upon packet reception.
> Otherwise, a read will block until either the kernel
> buffer becomes full or a timeout occurs. This is useful
> for programs like rarpd(8) which must respond to messages
> in real time. The default for a new file is off.
>
> ...
>
>and the OpenBSD man page probably says much the same thing.
>
>The "to_ms" argument to "pcap_open_live()", in BSD, is used to set the
>read timeout with BIOCSRTIMEOUT. If it's non-zero, reads from the BPF
>device will block until either
>
> 1) the kernel buffer fills up with packets
>
>or
>
> 2) the specified number of milliseconds elapses.
>
>libpcap never turns BIOCIMMEDIATE mode on.
Actually, the true meaning of BIOCGRTIMEOUT is quite a bit different from
the documentation. And i also belive, tho i'd have to check again, that
the timeout interval isn't from when the read is posted, but rather a maximum
sleep duration for one particular packet. So that if you have, say
100 packets, each which has a timeout interval slightly less than
the BIOCGRTIMEOUT set, the read still will NOT return, even tho
the read-timeout has passed.
bpf runs no backgound timeout mechanism, which has another side
effect on many of the bpf's: if you're using select to find the
next packet, then since the read doesn't block in select, then
BIOCGRTIMEOUT no longer provices any usefull service.
(ie: there is no background timeout which is actually managing the
temporal posting of the original read request...)
Now, if the select/BIOCGRTIMEOUT interaction isn't enough,
there is at least one non-kernel thread implementations which
turn the bpf reads into selects, and then sets O_NONBLOCK.
and then suffer from another sad interaction: if you then
turn around and libpcap, it sets BIOCGRTIMEOUT, and when
the thread's libpcap-read ends up really inside a select,
the select no longer notices the O_NONBLOCK, and doesn't
implement BIOCGRTIMEOUT.
and i think there's one more, but i may have forgotten it...
something to go with the way FIONREAD's implemented...
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
