Re: Filter works in tcpdump, but not in my libpcap

[Guy Harris <guy () alum mit edu>]

ness wrote:

> Below are a few interesting snippets of my code pertaining to libpcap. 
> All of the code is running on the main thread. Tcpdump and my 
> implementation both ran on an Airport Extreme card with WEP, but I doubt 
> that serves any relevance.

It probably isn't of direct relevance, but it at least indicates what 
type of machine you're running on, which limits the set of operating 
systems you're likely to be using; you didn't mention that, but the OS 
*is* of great relevance here.

Is it OS X, Linux, Windows, or some non-OS X BSD-flavored OS?

>   if( (pcap = pcap_open_live( dev, 65535, 1, 0, pcap_errbuf )) == NULL ) {
>     return (-1);
>   }

You're passing 0 as the to_ms argument.  To quote the pcap man page on 
OS X (which is the libpcap 0.8.3 man page on my Tiger machine, but that 
section, even though not present on some older versions of the pcap man 
page, applies to all versions):

	to_ms specifies the read timeout in milliseconds.  The read timeout is 
used to arrange that the read not necessarily return immediately when a 
packet is seen, but that it wait for some amount of time to allow more 
packets to arrive and to read  multiple packets from  the OS kernel in 
one operation.  Not all platforms support a read timeout; on platforms 
that don't, the read timeout is ignored.  A zero value for to_ms, on 
platforms that support a read timeout, will cause a read to wait forever 
to allow enough packets to arrive, with no timeout.

Mac OS X, and other BSD-flavored OSes, are platforms that support a read 
timeout, so a to_ms value of 0 means that you won't see any packets 
until the "store buffer" in the BPF code fills up and is rotated to the 
"hold buffer", so if you're not getting a lot of traffic to the 
specified MAC address, you could conceivably wait a *REALLY* long time 
before you see any traffic at all (libpcap defaults to setting the 
"store buffer" size to 32K).  Windows is another such platform, although 
I'm not certain whether a 0 to_ms value will block until the internal 
buffer fills up.

That could make it appear as if you're not capturing any traffic.

When capturing without the filter, you would probably get enough packets 
per second that the "store buffer" would fill up fairly quickly, so you 
wouldn't have much of a delay before seeing the packets.

Linux doesn't support a read timeout, and packets are seen immediately.

Tcpdump uses a to_ms value of 1000, so you wait no longer than a second 
after a packet arrives to see that packet.  You should probably do the same.

(No, you can't adjust the store buffer size.  That's not the right way 
to handle this in any case; a to_ms value of 0 is rarely, if ever, the 
right value to supply to pcap_open_live().)

By the way:

>   strcpy( filter, "(ether[0] == 0x00 && ether[1] == 0x09 && ether[2] == 
> 0xbf)"
>           " || (ether[6] == 0x00 && ether[7] == 0x09 && ether[8] == 
> 0xbf)" );

you can just pass a string constant to pcap_compile(); you don't have to 
copy that string constant to a char array first.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.