Hi, I just spent a few days debugging unexpected packet loss in my application. The first packet that passed the filter would often be missed, but the response that came immediately after would always make it through, as well as subsequent packets. This failure was inconsistent and difficult to reproduce.
After trying several other things, I upgraded from pcap 1.1.0 to pcap 1.6.1. This made the issue much worse. With the new version, the first packet was always lost instead of only sometimes, and future packets would frequently get lost as well. I found that disabling the mmap support worked around the problem. I think I understand why this was happening, at least in the context of TPACKET_V3. The issue is similar to #335. The kernel closes blocks after a certain timeout, handing them over to userspace. This happens whether the blocks contain any packets or not. My application uses libpcap in nonblocking mode with a separate event loop, and it didn't get notified of activity on the packet socket file descriptor when blocks expired. Eventually, a packet would pass the filter, but by this point, all blocks would be assigned to userspace, and the kernel would have nowhere to store it. Calling pcap_dispatch() from a timer seems to work around this by returning the blocks to the kernel. I'm now setting the pcap timeout to 50 ms (I wasn't setting it before), and running a timer every 50 ms that calls pcap_dispatch(). This looks more like a kernel issue than a libpcap issue to me, but I would appreciate a warning in the documentation that pcap_dispatch() needs to be called periodically, even if there's no activity on the selectable fd. Of course, if you can think of a way to work around this inside libpcap, that would be even better. Thanks, Aaron _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers