Does pypcap now require libpcap 1.0 or later?

[guyharris]

The current master branch's pcap.pyx' declares pcap_open_live(), but doesn't appear to use it; the pcapclass'sinitmethod appears to unconditionally callpcap_create()`.

If so, that means it won't work with pre-1.0 versions of libpcap that lack pcap_create() and pcap_activate() - in which case there's no need for it to declare pcap_open_live().

[hellais]

This is a good point.

As part of: #67 we starting using pcap_create() instead of pcap_open_live().

For some reason in 5de8fac#diff-c3876f456249b5e6c8991968ee76b8a5 I re-added pcap_open_live(), thinking that this would give us some level of greater backward compatibility.

I think it's reasonable to drop support for libpcap < 1.0 (which came out 10 years ago), though I think you are more knowledgeable about libpcap and what the tradeoffs between doing this or not doing this are.

What do you think would be best?

If we do go for deprecating 1.0, we should explicitly mention this in the readme and maybe add a check for it in the setup.py.

[guyharris]

The only tradeoff I see is that if you drop support for libpcap < 1.0 you drop support for old UN*Xes that shipped with older libpcaps, unless the user builds and installs a newer libpcap on their UN*X and builds pypcap to use it rather than the system libpcap, and may also drop support for older versions of WinPcap.

The UN*Xes I know of that ship libpcap are:

• Linux distributions;
• *BSDs;
• macOS;
• Solaris 11 and later;
• AIX.

sources.debian.org's libpcap entry appears to indicate that the first Debian release with libpcap 1.x was 6.0 "Squeeze", from February 2011.

blueprints.launchpad.net's libpcap Changelog for Jaunty and
blueprints.launchpad.net's libpcap Changelog for Karmic appear to indicate that the first Ubuntu release with libpcap 1.x was either 9.04 "Jaunty Jackalope", from April 2009, or 9.10 "Karmic Koala" from October 2009; the Jaunty entry has "libpcap (1.0.0-1) unstable; urgency=low" as its final entry and the Karmic entry has "libpcap (1.0.0-2ubuntu1) karmic; urgency=low" as the final entry.

The Fedora 12 release notes indicate that the first Fedora release to have libpcap 1.x was Fedora 12.

This email message says that RHEL 6.1 had libpcap 1.0.0; I don't know whether 6.0, or any previous releases, had it.

I'll let other people research other distributions.

Some poking around in the source repositories indicates that:

• FreeBSD 8.0, from November 2009, was the first release with libpcap 1.x;
• NetBSD 6.0, from October 2012, was the first release with libpcap 1.x;
• DragonFly BSD 2.4, from September 2009, was the first release with libpcap 1.x;
• OpenBSD has its own version of libpcap, but it picked up the pcap_create()/pcap_activate() API in OpenBSD 5.2, from November 2012.

Mac OS X 10.6 "Snow Leopard", from August 2009, was the first macOS release to have libpcap 1.x.

Solaris 11.4, from August 2018, has the pcap_create()/pcap_activate() API; as far as I know, earlier Solaris 11 releases had libpcap, but docs.oracle.com doesn't seem to document libpcap, so I don't know whether pre-11.4 releases had the APIs. Solaris 11 came out in November 2011.

AIX, however, still doesn't have the pcap_create()/pcap_activate() API as of the current release, 7.2. In the past, its libpcap was, umm, troublesome, supplying nanosecond-resolution time stamps (with no warning) and using its own different binary values for link-layer header types (including in capture files), but maybe they've decided that being source-incompatible and file-format-incompatible with the rest of the UN*X world wasn't such a good idea after all.

As for WinPcap, the WinPcap news page seems to indicate that WinPcap 4.1 was the first release with libpcap 1.x; all versions of Npcap have libpcap 1.x.

[hellais]

Thanks for the very thorough and well researched response @guyharris.

I think that dropping support for systems older than 10 years is reasonable, but I would like to hear if other users of pypcap have a problem with that.

I suppose that if they need to use such an old OS they can probably also rely on using an older version of pypcap which doesn't have python3 support.

I am going to leave this open for a bit more time and unless there is any strong argument to re-add pre 1.x pcap support I am going to just add a line in the documentation mentioning this (and perhaps a check in the setup.py script).