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.
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.
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
