As stated in the source, this module doesn't support live capture, it is simply a pcap file parser: pcapy clone in pure python This module aims to support exactly the same interface as pcapy, so that it can be used as a drop-in replacement. This means the module does not and probably will never support live captures. Offline file support should match the original though.
'pcap 1.1 in pip.
This is a module from Dug Song, wraps libpcap so the interface is familiar.
However, for some reason, if
pcap_open_live is called with a non-zero
pcap_loop will return if no packets were captured within the
to\_ms value. Its return value will be
This contradicts the man page:
pcap_loop() returns 0 if cnt is exhausted or if, when reading from a ``savefile'', no
more packets are available. It returns -1 if an error occurs or -2 if the loop ter-
minated due to a call to pcap_breakloop() before any packets were processed. It does
not return when live read timeouts occur; instead, it attempts to read more packets.
If called with the default
to_ms value (no timeout as per the help msg), the call to
pcap_loop seemsto block until a buffer is filled, which may not happen anytime soon if the traffic is low enough... (eg. while testing)
SWIG wrapper around libpcap. Not very pythonic, but very much like talking to libpcap directly.
Something strange however, the callback specified in
p.loop will receive 3 arguments:
pktlen, pktdata, timestamp.
This is not like libpcap, where the callbacks is called with
timestamp, pktdata, userdata
The loop respects the
to_ms parameter passed to
open_live, so that's good.
This one seems a bit obscure at first sight. It is, once again, a wrapper around libcap. It may look like all of the above, but almost all the libpcap calls are wrapped, which give us greater control over what we do with the underlying lib.
For example, the
pcap_set_buffer_size call is there. This is crucial when doing captures with a high packet rate as it allows to grow the bpf buffer from the default (2mb on linux) to something higher.