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.
A read timeout of 0 means "no timeout" in the sense that 2), above,
never happens - you don't get any packets until the kernel buffer fills
up.
I suspect you're supplying either a large "to_ms" value, or supplying 0
(which amounts to an infinite "to_ms" value).
Try specifying a small but non-zero "to_ms" value.
-
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
