Menu
▾
▴
#166 non-blocking libpcap + select = lost packets
It seems that libpcap is losing response packets when the come back to fast (when using a non-blocking pcap handler with select). For more details, please check http://stackoverflow.com/questions/11637063/asynchronous-libpcap-losing-packets.
Discussion
If you really are dropping packets, then, as I indicated in the stackoverflow question:
If the FD for the pcap_t is reported as readable by select() (or poll() or whatever call/mechanism you're using), there is no guarantee that this means that only one packet can be read without blocking.
If you use pcap_next_ex(), you will read only one packet; if there's more than one packet available to be read, then, if you do another select(), it should immediately return, reporting the FD as being readable again, in which case you'll presumably call pcap_next_ex() again, and so on. This means at least one system call per packet (the select()), and possibly more calls, depending on what version of what OS you're doing and what version of libpcap you have.
If, instead, you were to call pcap_dispatch(), with a packet-count argument of -1, that call will return all the packets that can be obtained with a single read operation and process all of them, so, on most platforms, you may get multiple packets with one or two system calls if there are multiple packets available (which, with high network traffic, as you might get if you're testing your program with a SYN flood, is likely to be the case).
In addition, on Linux systems that support memory-mapped packet capture (I think all 2.6 and later kernels do, and most if not all 2.4 kernels do), and with newer versions of libpcap, pcap_next_ex() has to make a copy of the packet to avoid having the kernel change the packet out from under the code processing the packet and to avoid "locking up" a slot in the ring buffer for an indefinite period of time, so there's an extra copy involved.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
After further investigation, I realized that even without select libpcap is losing packets. Please see this new SO question: http://stackoverflow.com/questions/11637063/asynchronous-libpcap-losing-packets. The workaround is to recompile libpcap without memory mapping support.
Administrators of the "libpcap" SourceForge project have superseded this tracker item (formerly artifact 3548076, now bug 166) with issue 169 of the "libpcap" GitHub project.