On Feb 3, 2010, at 5:03 AM, Marco De Angelis wrote:
> Guy Harris <guy <at> alum.mit.edu> writes:
>
>>> 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?
>
> Good question. Do you know how could I verify the buffer they stay in? Is
> there
> some printout I could add before calling pcap_dispatch to see what's in the
> kernel buffer and what in the userland buffer?
Yes, but you'd have to add it to libpcap. :-)
>> Is your program built as a 32-bit program or a 64-bit program?
>
> I was compiling for the native os.
"The native OS" supports both 32-bit and 64-bit userland code on 64-bit
processors (regardless of whether the kernel is running 32-bit or 64-bit).
Snow Leopard's GCC, if not given any -arch flags, builds 32-bit on 32-bit
machines and 64-bit on 64-bit machines.
> The lipo -info command says it is i386.
If it said something such as
Non-fat file: XXX is architecture: i386
then that means it's 32-bit only. If it said something such as
Architectures in the fat file: XXX are: x86_64 i386
then it's both 64-bit and 32-bit, and will run 64-bit on 64-bit machines.
> Just
> to be sure, I removed all other architectures (ppc and x86_64) from the list
> of
> compilation targets
Are you using an Xcode project or a Makefile or something else (including
"manually running gcc from the command line")? If it's an Xcode project, I'm
not sure what the default behavior would be.
> and recompiled. Nothing has changed. I will retry to build
> it for x86_64 and see if anything changes.
That would be interesting, because...
>> Presumably the tcpdump you downloaded and recompiled was recompiled on Snow
>> Leopard, which means that, unless your machine has a 32-bit processor
>
> It's a 64-bit processor.
...that means that if you just did a configure-and-make on tcpdump, it'd be
64-bit, and...
> Anyway, tcpdump works fine.
...it might be that 64-bit code works, even with sub-second timeouts, as of
10.6.2, but 32-bit code is broken, so...
> My line of reasoning is: if
> tcpdump works correctly and it always uses libpcap, then I should be able to
> capture using the same filter. I just cannot understand what my code (posted
> earlier) is doing differently from tcpdump.
...what it might be doing differently is "running 32-bit".
I'll look at what happens with 32-bit code as well.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
