On Dec 29, 2010, at 7:59 PM, Mathew Rowley wrote:
> I have been debugging why libpcap is unable to sniff packets in pcaprub (of
> metasploit) and have found a few things. Maybe some of you can enlighten me.
>
> 1. With this sample source - if the timeout variable is 0 in pcap_open_live,
> capturing does not work.
If the timeout variable is 0 in pcap_open_live(), then, on any system with BPF
(other than AIX, which is, as is often the case, a bit different), no packets
will be delivered until the kernel capture buffer fills up, so, if there's not
a lot of traffic, the program might wait a long time before any packets are
delivered. That's the case on *BSD and Mac OS X.
> Setting to >0 allows things to work.
A non-zero timeout, on systems with BPF, means that the packets will be
delivered when either
1) the kernel capture buffer fills up
*or*
2) the timeout expires
so you will not have to wait for the buffer to fill up before seeing the
packets.
A non-zero timeout value is rarely useful. (Note that some versions of Snow
Leopard have bugs where a timeout value < 1000 doesn't work - it acts like a
zero timeout value. It's fixed in current version, 10.6.5.)
> 2. It seems that the pcap_setnonblock will cause the pcap_handler to be
> called (although, I am not sure if I am using it correctly.) Comment out:
>
> pcap_setnonblock(pd, 1, error_buf);
>
> in the sample source to re-create.
"will cause the pcap_handler to be called", or "will *not* cause the
pcap_handler to be called"?
There is a bug in Snow Leopard (10.6.x) where non-blocking mode doesn't work:
http://thread.gmane.org/gmane.network.tcpdump.devel/4358/focus=4405
It's also buggy in at least some versions of FreeBSD and DragonFly BSD.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
