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.