[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] FreeBSD 5.4 & PCAP:  blocked read() on
From:       "Richard Huddleston" <rh.forums () verizon ! net>
Date:       2005-07-12 21:19:40
Message-ID: 001e01c58727$6ab10eb0$2e01a8c0 () tanagra
[Download RAW message or body]


----- Original Message ----- 
From: "Guy Harris" <guy@alum.mit.edu>
To: <tcpdump-workers@lists.tcpdump.org>
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  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_lookupnet(), and pcap_lookupnet() doesn't call read().

That's a relief.  In reading the code for those functions, I didn't see
anything that matched the stack trace.  I'm generally reluctant to blame my
tools, however, at least at first.

> The *actual* stack trace is probably pcap_loop() calling pcap_read_bpf()
> (through a function pointer), and pcap_read_bpf() calling read() (to
> read packets from the BPF device).
>
> 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'll wait until "enough" packets arrive (and "enough" could be a
> significant number), no matter how long that takes.
>
> > I don't get this behavior on Linux,
>
> The capture mechanism on Linux (PF_PACKET sockets) doesn't do buffering,
> so the recvfrom() done in libpcap on Linux will block waiting for a
> *single* packet to arrive.

The problem resolved to a clueless programmer--or, at least, one not aware
at the time of what to expect from a platform that honors the to_ms argument
to pcap_open_live().



-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
[prev in list] [next in list] [prev in thread] [next in thread]