Why is there a long delay between pcap_loop () and receiving a packet?
I am writing a sniffer using libpcap. My problem is that there is a 7-10 second delay between calling pcap_loop () or pcap_next () and actually receiving the packet (the calling function of the call). However, if I use wireshark with the same filter on the same device, there is no such delay after clicking the Start button. Why is there a delay in my program and is there a way to fix it?
I am working on atheros wifi chips. The device is configured for monitoring mode using
airmon-ng start wlan0
I'm sure there is a lot of traffic to listen to because I see packets in wireshark. Thank.
source to share
I am using 10000
The to_ms argument for pcap_open_live()
and pcap_set_timeout()
is in milliseconds.
10,000 milliseconds is 10 seconds.
Try using 1000, which is the tcpdump value - this will reduce the latency to 1 second - or use 100, which is the Wireshark value - this will reduce the latency to 1/10 of a second.
I read in a tutorial about this field: "at least on some platforms this means you can wait until enough packets arrive before watching any packets, so you should use a non-zero timeout"
In this tcpdump.org tutorial "How to use the libpcap tutorial" and this question has been added to 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 this. :-)
I would have to spend some time analyzing the Linux kernel code (again) to see what impact the 0 timeout value has on newer kernels. However, when writing code that uses libpcap / WinPcap for live recording, you should always act as if you were writing code for that platform; your code will be more portable to other platforms and won't break if the zero timeout behavior changes.