What does to_ms = -1 do on winpcap and linux libpcap? - macos

Question

I am trying to port a libpcap based program to macos, and it seems to be written for windows and linux. In the pcap_open_live function, the read timeout was set to -1, same with PacketOpen, and on macOS, this causes an error when trying to open the interface, BIOCSRTIMEOUT: Invalid Argument. I am unable to find any documentation on what a -1 read timeout actually does. Additonally, is there a version of this which will allow me to do the same thing on a BPF based libpcap?

Answer 1

What does to_ms = -1 do on winpcap and linux libpcap?
Nothing predictable. To quote the tip-of-the-master-branch pcap(3pcap) man page:
packet buffer timeout
If, when capturing, packets are delivered as soon as they
arrive, the application capturing the packets will be woken up
for each packet as it arrives, and might have to make one or
more calls to the operating system to fetch each packet.
If, instead, packets are not delivered as soon as they arrive,
but are delivered after a short delay (called a "packet buffer
timeout"), more than one packet can be accumulated before the
packets are delivered, so that a single wakeup would be done for
multiple packets, and each set of calls made to the operating
system would supply multiple packets, rather than a single
packet. This reduces the per‐packet CPU overhead if packets are
arriving at a high rate, increasing the number of packets per
second that can be captured.
The packet buffer timeout is required so that an application
won’t wait for the operating system’s capture buffer to fill up
before packets are delivered; if packets are arriving slowly,
that wait could take an arbitrarily long period of time.
Not all platforms support a packet buffer timeout; on platforms
that don’t, the packet buffer timeout is ignored. A zero value
for the timeout, on platforms that support a packet buffer time‐
out, will cause a read to wait forever to allow enough packets
to arrive, with no timeout.
NOTE: the packet buffer timeout cannot be used to cause calls
that read packets to return within a limited period of time,
because, on some platforms, the packet buffer timeout isn’t sup‐
ported, and, on other platforms, the timer doesn’t start until
at least one packet arrives. This means that the packet buffer
timeout should NOT be used, for example, in an interactive
application to allow the packet capture loop to ‘‘poll’’ for
user input periodically, as there’s no guarantee that a call
reading packets will return after the timeout expires even if no
packets have arrived.
Nothing is said there about a negative timeout; I'll update it to explicitly say that a negative value should not be used. (Not on Windows, not on macOS, not on Linux, not on *BSD, not on Solaris, not on AIX, not on HP-UX, not on Tru64 UNIX, not on IRIX, not on anything.)
By setting the timeout to -1, they probably intended to put the pcap_t into "non-blocking mode", where an attempt to read will return immediately if there are no packets waiting to be read, rather than waiting for a packet to arrive. So, instead, provide a timeout of, for example, 100 (meaning 1/10 second) and use pcap_setnonblock() after the pcap_open_live() call to put the pcap_t into non-blocking mode. That should work on all platforms.