Sam Pierson wrote:
What I meant was that in a situation where you send a single packet,
you can't pick it up as soon as it comes, you have to wait for some
other timeout value that you supply... the problem is that it only has
a time resolution of 1ms, so for applications that depend on a finer
On 7/12/05, Guy Harris <[EMAIL PROTECTED]> wrote:
> Sam Pierson wrote:
>
> > This is unavoidable, as the problem lies within FreeBSD, correct?
>
> To what does "this" refer?
What I meant was that in a situation where you send a single packet,
you can't pick it up as soon as it comes, you have to
- Original Message -
From: "Guy Harris" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, July 12, 2005 3:15 AM
Subject: Re: [tcpdump-workers] FreeBSD 5.4 & PCAP: blocked read() on
pcap_lookupnet()
> Richard Huddleston wrote:
>
> > (gdb) where
> > #0 0x2
Sam Pierson wrote:
This is unavoidable, as the problem lies within FreeBSD, correct?
To what does "this" refer?
It's an intended feature that a zero timeout will wait until "enough"
packets arrive, so if you're not in non-blocking mode, it is, indeed,
"unavoidable" that a read will block un
On 7/12/05, Guy Harris <[EMAIL PROTECTED]> wrote:
> Richard Huddleston wrote:
>
> It'll block waiting for "enough" packets to arrive to fill up the kernel
> BPF buffer - or, if a non-zero timeout was supplied in the
> pcap_open_live() call, until the timer expires. If the timeout was
> zero, it'l
Richard Huddleston wrote:
(gdb) where
#0 0x280ee6fb in read () from /lib/libc.so.5
#1 0x28090c57 in pcap_lookupnet () from /usr/lib/libpcap.so.3
#2 0x28091adb in pcap_loop () from /usr/lib/libpcap.so.3
GDB is buggy, it appears, and printed a bogus stack trace; pcap_loop()
doesn't call pcap
FreeBSD 5.4
"Stock" pcaplib
I'm blocking on a read() invoked by pcap_lookupnet():
Program received signal SIGINT, Interrupt.
0x280ee6fb in read () from /lib/libc.so.5
(gdb) where
#0 0x280ee6fb in read () from /lib/libc.so.5
#1 0x28090c57 in pcap_lookupnet () from /usr/lib/libpcap.so.3
#2 0x280
