6

I'm writing a sniffer using libpcap. My problem is that there's a 7-10 second delay between calling pcap_loop() or pcap_next() and actually getting a packet(the callback function being called). However, if I use wireshark with the same filter on the same device, there is no such delay after I hit the "start" button. Why is there a delay in my program and is there a way to fix that?

I'm working on atheros wifi chips. The device is set to monitor mode using 

airmon-ng start wlan0

I'm sure there're plenty of traffic to listen to, for I can see the packages in wireshark. Thank you.

Nick Zhang
  • 199
  • 2
  • 7
  • What value are you passing as the *to_ms* argument to `pcap_open_live()` or `pcap_set_timeout()` in your program? –  Apr 26 '15 at 19:06
  • Thank you for your attention. I'm using 10000. Also, I'm using Debian linux. I read on a tutorial about this field: " on at least some platforms, this means that you may wait until a sufficient number of packets arrive before seeing any packets, so you should use a non-zero timeout"But am not sure I understand. Is linux among these platforms? – Nick Zhang May 12 '15 at 09:48

1 Answers1

6

I'm using 10000

The to_ms argument to pcap_open_live() and pcap_set_timeout() is in milliseconds.

10000 milliseconds is 10 seconds.

Try using 1000, which is the value tcpdump uses - that'll reduce the delay to 1 second - or using 100, which is the value Wireshark uses - that'll reduce the delay to 1/10 second.

I read on a tutorial about this field: " on at least some platforms, this means that you may wait until a sufficient number of packets arrive before seeing any packets, so you should use a non-zero timeout"

The tutorial in question is the tcpdump.org "How to use libpcap" tutorial, and the passage in question was added in this CVS commit:

revision 1.8
date: 2005/08/27 23:58:39;  author: guy;  state: Exp;  lines: +34 -31
Use a non-zero timeout in pcap_open_live(), so you don't wait for a
bufferful of packets before any are processed.

Correctly explain the difference between pcap_loop() and
pcap_dispatch().

In sniffex.c, don't print the payload if there isn't any.

so I'm familiar with it. :-)

I'd have to spend some time looking at the Linux kernel code (again) to see what effect a timeout value of 0 would have on newer kernels. However, when writing code that uses libpcap/WinPcap to do live captures, you should always act as if you're writing code for such a platform; your code will then be more portable to other platforms and will not break if the behavior of a zero timeout changes.

  • I've modified the timeout to 100 and now the delay disappeared, thank you so much! I'm still a bit confused though. What does this delay really mean? When a package arrives, isn't the callback function immediately called? Or are packages buffered for "to_ms"time and then dealt together? What is the use of this delay? Thank again! – Nick Zhang May 13 '15 at 06:37
  • One more thing~ I try to capture in wireshark and in my program beacons from my own AP. But there isn't any. or very little(less than 10 in one minute). However if I use airodump-ng, there are much more beacons from my station. Does this mean packages are dropped by, say, kernel/driver? But wireshark says Dropped:0. – Nick Zhang May 13 '15 at 06:42
  • 2
    "When a package arrives, isn't the callback function immediately called?" No. When a packet arrives, with some packet capture mechanisms (BPF on all but AIX, DLPI on Solaris, TPACKET_V3 on Linux, WinPcap on Windows), it's put in a buffer. Subsequent packets are put after it in the buffer; the buffer is handed to userland either when it fills up or when the timer expires. That reduces the number of system calls per packet with heavy traffic, making capture more efficient. See [the BPF paper](http://www.tcpdump.org/papers/bpf-usenix93.pdf). –  May 13 '15 at 06:51
  • "One more thing~ I try to capture in wireshark and in my program beacons from my own AP. But there isn't any. or very little(less than 10 in one minute)." So you are capturing beacon packets? If so, that implies you're capturing in monitor mode. If you see *no* beacons, that might be because you're not capturing in monitor mode, in which case you'll only see data packets sent to or from the machine doing the capturing. Are you getting packets with Ethernet headers or 802.11 headers? Are you using a capture filter? –  May 13 '15 at 06:53
  • Sorry for lack of background information. I set my card to monitor mode with airmon-ng.Then I use airodump-ng on the new mon0 interface. That's where i see plenty of beacon packages from my ap. Then, in my own program i apply filter "subtype beacon", but get no or few packages from my AP. I then used wireshark and capture with the same filter. Still, there were little beacons from my own AP. I suspect a loss of packages, but can't be sure. Is there a mechanism in libpcap to get loss packages count? – Nick Zhang May 14 '15 at 06:56
  • Even more weirdly. In wireshark I get plenty of beacons from another AP. D-link1234. But in airodump-ng there were very little. I'm not sure about airodump's implementation, but there must be some lost packages. I get packages with 802.11 headers, and I was able to get correct RSSI from the packages(no.22 byte). – Nick Zhang May 14 '15 at 07:00
  • So, after you've used airmon-ng to create the mon0 interface, on what device are you capturing with your program and with Wireshark? Are you also capturing on mon0? –  May 14 '15 at 20:37
  • "Is there a mechanism in libpcap to get loss packages count?"? The `pcap_stats()` API will give you the "number of packets dropped because there was no room in the operating system's buffer when they arrived, because packets weren't being read fast enough", so you can find out that particular lost packets count. The "number of packets dropped by the network interface or its driver" is not guaranteed to be supplied (i.e., it might be 0 even if the interface or its driver *did* drop packets). –  May 14 '15 at 20:42
  • I am using mon0, even though I do not thinks it's necessary. For all I need are beacons, and they don't need to be in monitor mode to be captured(at least I think so). I'll try 'pcap_stats()' right away. Speaking about package loss. I tried 'ifconfig mon0' to see packets dropped, which is nearly equal to package received. Does this count means packages that aren't read by any programs? – Nick Zhang May 15 '15 at 00:25
  • "For all I need are beacons, and they don't need to be in monitor mode to be captured(at least I think so)." I strongly suggest you test that rather than assuming that. At least some Linux drivers supply 802.11 headers only in monitor mode, and supply "fake Ethernet" headers when not in monitor mode, and the only packets that can easily be given "fake Ethernet" headers are data packets, not management packets like beacons. –  May 15 '15 at 06:26