I thought I’d document the solution to this problem I had.
The API libpcap is the standard cross-platform way of sniffing packets off the network. It works on Windows (winpcap), macOS, and all the Unixes. It’s better than simply opening a “raw socket” on Unix platforms because it takes advantage of higher performance capabilities of the system, including specialized sniffing hardware.
Traditionally, you’d open an adapter with pcap_open(), whose function parameters set options like snap length, promiscuous mode, and timeouts.
However, in newer versions of the API, what you should do instead is call pcap_create(), then set the options individually with calls to functions like pcap_set_timeout(), then once you are ready to start capturing, call pcap_activate().
I mention this in relation to “TPACKET” and pcap_set_immediate_mode().
Over the years, Linux has been adding a “ring buffer” mode to packet capture. This is a trick where a packet buffer is memory mapped between user-space and kernel-space. It allows a packet-sniffer to pull packets out of the driver without the overhead of extra copies or system calls that cause a user-kernel space transition. This has gone through several generations.
One of the latest generations causes the pcap_next() function to wait forever for a packet. This happens a lot on virtual machines where there is no background traffic on the network.
This looks like a bug, but maybe it isn’t. It’s unclear what the “timeout” parameter actually means. I’ve been hunting down the documentation, and curiously, it’s not really described anywhere. For an ancient, popular APIs, libpcap is almost entirely undocumented as to what it precisely does. I’ve tried reading some of the code, but I’m not sure I’ve come to any understanding.
In any case, the way to resolve this is to call the function pcap_set_immediate_mode(). This causes libpccap to backoff and use an older version of TPACKET such that it’ll work as expected, that even on silent networks the pcap_next() function will timeout and return.
I mention this because I fixed this bug in my code. When running inside a VM, my program would never exit. I changed from pcap_open_live() to the pcap_create()/pcap_activate() method instead, adding the setting of “immediate mode”, and now things work. Performance seems roughly the same as far as I can tell.
I’m still not certain what’s going on here, and there are even newer proposed zero-copy/ring-buffer modes being added to the Linux kernel, so this can change in the future. But in any case, I thought I’d document this in a blogpost in order to help out others who might be encountering the same problem.
*** This is a Security Bloggers Network syndicated blog from Errata Security authored by Robert Graham. Read the original post at: https://blog.erratasec.com/2018/07/some-changes-in-how-libpcap-works-you.html