2.6.0/2.6.1 release

[guedou]

This issue tracks the associated 2.6.0 release. As usual, feel free to comment down below to have some features/bugs included before the final release.

Note to package maintainers: it is important to point out that special care should be taken when porting/testing this release. The plateform-specific code aimed at reading the network configuration (interfaces, routes, etc.) has been entirely rewritten on both Linux and *BSD flavors. Plateforms that were tested include: Windows, Linux, OpenBSD, NetBSD, FreeBSD, Darwin. Other plateforms have not been tested, therefore we encourage maintainers to perform additional testing.

Changelog

General

• [removal] DROP SUPPORT OF PYTHON 2.7

• Python 3.11-3.13 support. The full range of supported Python versions is therefore 3.7-3.13
• Improve packaging (pyproject.toml) and version handling. Scapy will now include wheels on pypi.
• We welcome Nils Weiss (polybassa) as a new maintainer !

Main changes

• [major] support for RFC6874-like scope identifiers. This is very useful for multicast IPs as one can now do the following on L3: sr(IP(dst="224.0.0.1%eth0")/..., multi=True)
• [major] using the iface= argument is deprecated on level3 functions (send, sr, sr1), as its behavior was undefined. It remains in use for level2 functions (sendp, srp, srp1). RFC6874-like scope identifiers (see just above) should be used.
• [major] the internals that read the routes and interfaces configuration have been rewritten on Linux and BSD:
  • on linux, to use RTNETLINK. (this should help on machines that have huge BPG tables)
  • on *BSDs, to use PF_ROUTE.
  • on Linux, NetBSD and FreeBSD, link-local and multicast routes should now properly be loaded
• [new] Windows protocols:
  • DCE/RPC: DCERPC_Client and DCERPC_Server with support for NCACN_IP_TCP and NCACN_NP
  • SMB2/3:
    • Protocol refactor, many more SMB2/3 structures supported
    • Server (class + 'simple' util smbserver()) (2.0.2 to 3.1.1)
    • Client (class + interactive CLI smbclient()) (2.0.2 to 3.1.1)
    • SMB socket, RPC over SMB socket, etc.
  • Kerberos:
    • KerberosSSP to use in SMB/RPC clients/servers, [MS-KILE] variants, SFU and more !
    • Crypto: use cryptography, latest RFC8009, GSS_WrapEx support, typing, etc.
    • Util functions krb_as_req, krb_tgt_req, kpasswd (both modes), etc.
    • Ticketer++: ccache support, ask/renew/resign/edit tickets, etc
  • NTLM:
    • refactor, clean SSP
  • Extensive GSSAPI / SPNEGO support !
  • LDAP
    • Fixes, ASN.1 Windows variation support
    • dclocator, answering machine for "LDAP PING", etc.
    • add a (very) basic LDAP_client (support for various binding mechanisms, encryption, etc.)
• [dep] Support for recent cryptography (42/43.0) versions
• [new] CLI improvements
  • [breaking] Scapy CLI configuration now available in ~/.config/scapy/startup.py. This follows XDG variables. (Older ~/.scapy_startup.py is now non functional)
  • Support for bpython, ptpython and ptipython
• [new] Wireshark extcap interfaces support (load_extcap())
• Automaton:
  • fixes memory usage on Windows
  • support for EOF events
  • spawn() mode, better socket.socket support
• [breaking] StreamSocket changes, support for TCP reassembly, etc. TCPSession(app=True) must no longer be used with StreamSocket. Custom sessions are marked as unstable.
• Use L3RawSocket(6) automatically on the loopback interface on linux
• L3pcapSocket (the default L3 on Windows or when libpcap is used) now follows the same behavior as other L3 sockets when routing
• the sr* class of functions now properly supports sending on multiple interfaces (Windows & Linux)
• performance issues with the sr* class of functions have also been fixed
• manufdb (from wireshark) is now bundled and cached in ~/.cache/scapy, as it is no longer shipped as a standalone file in Wireshark.
• Improve builtin answering machines (dnsd, llmnrd, nbnsd, dhcpd...). Add mdnsd for mDNS support
• Fix performance issues with nested *ListFields
• [new] conf.nameservers contains the DNS servers. Also adds dns_resolve()
• [new] SSHv2 layer
• [breaking] Rework Session objects
• Fix L2 address computation when ARP is used over Ether (intrusive ARPs, bad guessing..)
• [breaking] change sendpfast loop argument to be consistent with sendp
• automaton: improve graph() to include implicit links
• HTTP:
  • [new] add HTTP_Client and HTTP_Server which support the same SSPs as Windows
  • rework http_client
  • various fixes to reassembly when using TCPSession
• TLS:
  • support for TLS 1.3 post handshake
  • support for EdDSA signatures / keys (ed25519/ed448)
  • various fixes (ffdhe generation, middlebox compat)
  • support choosing of curve, signature algorithms, etc.
• More options supported in DHCP(v6), IPv6, DNS/LLMNR (special thanks to evverx)
• Bluetooth, 802.11: new payloads supported
• IPSEC: AES-NULL-GMAC support
• [breaking] Merge EAPOL contrib into EAP
• fix latex theme
• IKEv2, ISAKMP: NAT traversal support, and other fixes (notify, ...)
• Minor fixes in Netflow, NTP, SCTP, TACACS
• [deprecation] Deprecate Winpcap support on Windows (please use Npcap instead if you are not already using it).
• [removal] Remove ubberlogger.
• cache get_if_hwaddr for performance
• fix arping without IP
• [new] tcpros layer (ROS 1.1)
• many more fixes

Automotive changes

TODO

[MeitarR]

When will it be released?
I see that the milestone is already passed due, can't wait for the new features 🙏

[guedou]

We are indeed late on the schedule. Our current goal is the end of February, but it might be subject to another shift.

[dijital20]

Hi there, any update on when this will be resolved?

[gpotter2]

I've just released '2.6.0rc1'.

[ygavenchuk]

Hello. Any updates about the release? Is it possible to release, say rc2 with the last fixes?

[gpotter2]

Just released '2.6.0rc2'. Try it out via pip install --pre scapy

Expect the full 2.6.0 within 1 or 2 weeks.

Edit: delayed slightly because of #4538, still on track for the end of this week.

[gpotter2]

2.6.0 is out.
Sorry for the wait.

[gpotter2]

@charles2910 Hi & sorry for the ping. Wanted to let you know that we have a new release available.

Btw is there a pseudo-automated way of doing this kind of reports? Fedora has super great tools for upstream, for instance https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/hotness/ automatically reports new releases to downstream package maintainers. Do you know if there's something similar for Debian?

I'm realising it takes quite some time to notify all package maintainers of the new release :) To anyone reading here, do you have a preference? Some projects (like Fedora) have it automated, which is handy. We could also send a grouped email to maintainers when releases happen, if people are up for it. Feel free to tell me if interested.

Thanks a lot for your help, cheers

[gpotter2]

@dhgutteridge Hi. Really sorry for bothering.
I did not find a contact form (or similar) to notify of the new release on https://pkgsrc.se/net/scapy. Is there such a thing (like Arch-Linux has, or Fedora) ? Or is the only way to submit a bug report? What is the favorite mean of contact?
Thanks a lot, cheers

[gpotter2]

@bluhm Hi, also very sorry for bothering.
I didn't find a contact method on https://openports.eu/ports/net/scapy or a way of noticing that new releases are available. Is there a preferred method to do that?
Thanks a lot for your help, cheers

[charles2910]

Hi, @gpotter2 and thanks for pinging me! (don't be sorry, I really enjoy it since I can't keep track of everything all the time)

We do have some automated tools that scans regularly the upstream's to see if there is a new release, but it didn't pickup scapy 2.6.0 yet. I'm trying to subscribe to all Github repos so I get the email for the new releases instantly but I was missing scapy (now I'm subscribed :-)

Also kudos for reaching out packagers, it's a very nice gesture!

Now let's see if I can prepare and upload to Debian before Sunday ends.

Cheers

[charles2910]

Hi again :-)

I'm just finishing packaging 2.6.0 and I saw the advertised support to python 3.13. At the same time, lintian has showed me the following warning:

I: scapy source: uses-deprecated-python-stdlib crypt (deprecated in Python 3.11, removed in Python 3.13) [scapy/modules/krack/automaton.py:11]
I: scapy source: uses-deprecated-python-stdlib crypt (deprecated in Python 3.11, removed in Python 3.13) [scapy/modules/krack/automaton.py:12]
I: scapy source: uses-deprecated-python-stdlib crypt (deprecated in Python 3.11, removed in Python 3.13) [scapy/modules/krack/automaton.py:13]
I: scapy source: uses-deprecated-python-stdlib crypt (deprecated in Python 3.11, removed in Python 3.13) [scapy/modules/krack/crypto.py:10]
I: scapy source: uses-deprecated-python-stdlib crypt (deprecated in Python 3.11, removed in Python 3.13) [scapy/modules/krack/crypto.py:11]
I: scapy source: uses-deprecated-python-stdlib uu (deprecated in Python 3.11, removed in Python 3.13) [scapy/contrib/pnio_rpc.py:14]
I: scapy source: uses-deprecated-python-stdlib uu (deprecated in Python 3.11, removed in Python 3.13) [scapy/fields.py:24]
I: scapy source: uses-deprecated-python-stdlib uu (deprecated in Python 3.11, removed in Python 3.13) [scapy/layers/dcerpc.py:29]
I: scapy source: uses-deprecated-python-stdlib uu (deprecated in Python 3.11, removed in Python 3.13) [scapy/layers/spnego.py:20]
I: scapy source: uses-deprecated-python-stdlib uu (deprecated in Python 3.11, removed in Python 3.13) [scapy/utils.py:14]

Indeed there is a removal warning on python's website 1 2. Were you guys aware of this? Should I open an issue?

[gpotter2]

Hi,
Those warnings appear to be bogus. I think there's a bug in lintian here..

We import cryptography and uuid which indeed include the words crypt and uu, but are completely different 😝 You can see pretty easily how this issue could happen though :)

I'm just finishing packaging 2.6.0

That was fast ! Thanks a lot

[charles2910]

Oh dear, now I must apologize. I blindly trusted lintian on this one and didn't check the files... Sorry about this.

I think I was a bit anxious to upload the new version and skipped some steps. Good news is I've uploaded to experimental already!

[dhgutteridge]

@dhgutteridge Hi. Really sorry for bothering. I did not find a contact form (or similar) to notify of the new release on https://pkgsrc.se/net/scapy. Is there such a thing (like Arch-Linux has, or Fedora) ? Or is the only way to submit a bug report? What is the favorite mean of contact? Thanks a lot, cheers

You can ping us however you like, e.g., this is fine. (Once a maintainer knows about a new package update, we may record it centrally in a "todo" document, though that approach varies.)

pkgsrc is in a freeze at the moment for stable branching, so I can't carry this update yet. Though it should be un-frozen soon. I have already looked at packaging and completed it. Though I haven't looked through test results in any detail.

A couple of comments. The generated wheel (at least, what I get) doesn't install the scapy.1 man page. I see there was specific handling for it, and that was removed in refactoring relatively recently. (In my case, I've simply worked around this locally for now by copying it over to our release tree.)

I was a little surprised that "Version" ends up being a date and not 2.6.0, and downstream packagers are advised to forcibly override this in the environment. But, anyway, that's obviously been handled.

Thanks for all your work on this!

[gpotter2]

You can ping us however you like, e.g., this is fine.

Great.

The generated wheel (at least, what I get) doesn't install the scapy.1 man page.

You are right, this was lost in the migration to pyproject.toml. I'll take a look on how to add it back for future releases.

I was a little surprised that "Version" ends up being a date and not 2.6.0

The date is a fallback and isn't supposed to happen. If you cloned the repo while fetching the git tags, they're supposed to be used. If you downloaded a zip file it's supposed to be automatically baked in by git. Could be a bug though, what method did you use?

Thanks

[dhgutteridge]

The generated wheel (at least, what I get) doesn't install the scapy.1 man page.

You are right, this was lost in the migration to pyproject.toml. I'll take a look on how to add it back for future releases.

I've opened this as issue #4549 for tracking. Thanks.

I was a little surprised that "Version" ends up being a date and not 2.6.0

The date is a fallback and isn't supposed to happen. If you cloned the repo while fetching the git tags, they're supposed to be used. If you downloaded a zip file it's supposed to be automatically baked in by git. Could be a bug though, what method did you use?

We download from GitHub as https://github.com/secdev/scapy/archive/v2.6.0.tar.gz.

I had inferred this was expected behaviour because of the section in development.rst which begins "When packaging Scapy, you should build the source while setting the SCAPY_VERSION variable, in order to make sure that the version remains consistent."

Having analyzed, I see that _parse_tag() doesn't handle release version formats, so it throws "tag has invalid format", and we end up with the date fallback instead. I've submitted #4548, which I tested and resolves the issue for me. (You may want to do it differently, of course.)

[charles2910]

Hey guys, I saw there were some bugfixes after the release. Are you guys considering doing a patch release (2.6.1)? If not, could you consider it? For what I have seen #4558, #4560, #4567, #4569 and 28287eb are the most important fixes and the ones I'm considering to add as patches if there is no patch release. Should I add something else?

[gpotter2]

Hi, thanks for reaching out.
You're right, there have been too many packaging issues with this release. We'll have 2.6.1 released by the end of the week.

The ones you listed are enough, #4560 being to me the most critical (as it can't really be worked around).

I want to take a second look at the code handling XDG and to make sure I didn't miss some other case that would result in a crash, then we'll be good to go.

[gpotter2]

FTR 2.6.1 is out and should address the issues listed here. Thank you all for the feedback.