On Feb 1, 2010, at 1:08 AM, Marco De Angelis wrote:
> The problem is that the packets are not delivered to the application. More
> specifically,
> it seems that libpcap captures them, but the pcap_dispatch (and pcap_loop as
> well) does
> not deliver packets to the pcap_handler.
What do you mean by "libpcap captures them"? Do you mean that libpcap reads
the packets into the userland buffer attached to the pcap_t, or that *BPF*
captures them (i.e., they get put into the *kernel* buffer for the BPF device)
but libpcap doesn't read them into its userland buffer?
> Packets seems to remain in the buffer and they
> get delivered only when the buffer is full.
If you're referring to the BPF kernel buffer, that sounds as if the timeout
mechanism isn't working. That was a bug that happened in 10.6 and 10.6.1 for
64-bit programs specifying sub-second timeouts, but that's fixed in 10.6.2 -
*if* you're using libpcap (rather than using raw BPF; the bug in BPF isn't
fixed, it's just worked around in libpcap).
Is your program built as a 32-bit program or a 64-bit program?
> Tcpdump worked on Snow Leopard (the one that comes with the O.S.), and also
> the one I downloaded and
> recompiled. I recompiled it just to be sure that they didn't do some "trick"
> to make it work.
> Maybe I just don't trust the Authority :)
Which authority? The one at
http://www.opensource.apple.com/source/tcpdump/tcpdump-27/
(you might have to sign up for ADC to view that, but it's free)?
Presumably the tcpdump you downloaded and recompiled was recompiled on Snow
Leopard, which means that, unless your machine has a 32-bit processor, it was
compiled, by default, 64-bit. Perhaps something's broken with 32-bit programs,
now (it shouldn't be, as the workaround in libpcap shouldn't change what
libpcap does in 32-bit mode, but perhaps there's some other issue).-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
