This latest version of scapy has improved BSD and SunOS support, among
other changes. I've continued our DragonFly support, since we were
already carrying patches for it. (These should be submitted upstream.)
(This also addresses PR pkg/54550, submitted by Gabriel Potter of
scapy. Thanks for the reminder, and for all your work on your project!)
I have tested a pkgsrc build and scapy regression suite in the
following environments:
NetBSD 8.1_STABLE with Python 3.6.9
NetBSD 9.99.17 with Python 3.7.5
DragonFly BSD 5.6.2 with Python 3.6.9
OpenIndiana Hipster 2019.04 with Python 3.7.5
Fedora Linux 30 with Python 3.7.5
Significant details from the upstream change summaries:
2.4.3
Main Changes
Core
364 commits since v2.4.2
better native support for FreeBSD, NetBSD, OpenBSD
Windows: native RAW sockets support, load interfaces/routes using C calls, ...
Solaris: fixed support
latency improvements
sniff() can be used to test BPF fiters on pcap files
more unit tests and Python3 compatibility
asynchronous sniffing
UTScapy vim syntax highlighting
drop distutils for setuptools
Console / IPython integration improvements
Layers
Major changes
New
HTTP (from the deprecated scapy-http module), TLS 1.3, ATA over Ethernet, OVD, IEC 60870-5-104, enip, ...
Improved
NetflowV9, ISOTP, Zigbee, RTR, BLE, PPI, DNS, LLDP, ...
Bluetooth/BTLE rework
PPI / 802.11 improvements
2.4.2
Main changes
Gabriel Potter is officially part of the Scapy maintainers team
PEP08 compliance (see #1277)
Speed improvements (see #642)
Core
253 merged pull requests since v2.4.0
Python 3.7 support
Enhanced Windows support
unit testing is now 100% tox based
Layers
Major changes
Many automotive related layers added (ISO-TP...)
New
EtherCat
OPCDA
SOCKS
USBpcap
RPKI
Improved
MACsec, MQTT, MPLS, DNS, ARP, Dot15d4, Zigbee, Bluetooth4LE, RadioTap ...
Enhanced monitor mode support
Other
addresses a v2.4.0 vulnerability
2.4.0
Main changes
Python3 support
85% code coverage
Core
Pcap/PcapNg improvements
enhanced Windows support
OpenBSD improvements
OSX 802.11 monitor mode
Krack AP module
iPython support
automatically tested on Linux, OSX & Windows
...
Layers
Major changes
TLS (including TLS1.3), X.509 ...
New
HTTP/2, EAP-TTLS, TACACS, MQTT ...
Improved
IPv6, SCTP, NTP, PPTP, CDP, BGP, ISIS ...
Performing substitutions during post-patch breaks tools such as mkpatches,
making it very difficult to regenerate correct patches after making changes,
and often leading to substituted string replacements being committed.
either because they themselves are not ready or because a
dependency isn't. This is annotated by
PYTHON_VERSIONS_INCOMPATIBLE= 33 # not yet ported as of x.y.z
or
PYTHON_VERSIONS_INCOMPATIBLE= 33 # py-foo, py-bar
respectively, please use the same style for other packages,
and check during updates.
Use versioned_dependencies.mk where applicable.
Use REPLACE_PYTHON instead of handcoded alternatives, where applicable.
Reorder Makefile sections into standard order, where applicable.
Remove PYTHON_VERSIONS_INCLUDE_3X lines since that will be default
with the next commit.
Whitespace cleanups and other nits corrected, where necessary.
This release adds a contrib section filled with old contributions that were not distributed with Scapy yet: CDP, IGMP, MPLS, CHDLC, SLARP, WPA EAPOL, DTP, EIGRP, VQP, BGP, OSPF, VTP RSVP, EtherIP, RIPng, and IKEv2. It fixes some bugs.
Remove devel/py-ctypes (only needed by and supporting python24).
Remove PYTHON_VERSIONS_ACCEPTED and PYTHON_VERSIONS_INCOMPATIBLE
lines that just mirror defaults now.
Miscellaneous cleanup while editing all these files.
This release include many bugfixes, most of them for Windows platforms,
thanks mainly to Dirk Loss. There is also VRRP and SCTP protocols
suppor thanks to zer0, IPython support.
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
