NetworkManager 1.58.1 landed on Friday and the headline fix is a regression that shipped in 1.58 itself: profiles written with key-mgmt=wpa-psk stopped reconnecting automatically to WPA3 networks using SAE. If you upgraded a fleet of laptops to 1.58 and started getting tickets about Wi-Fi that connects once and never comes back after a suspend, this is the release you want. The rest of the changelog is smaller but useful, covering IPv4 forwarding on modem interfaces, several systemd-resolved edge cases around invalid nameservers, a DHCP warning that will save somebody an afternoon, and tighter handling of certificate paths in private 802.1X profiles.
The short answer
NetworkManager 1.58.1 fixes a regression introduced in 1.58 where connection profiles using key-mgmt=wpa-psk failed to reconnect automatically to WPA3 networks running SAE. The release also enables IPv4 forwarding on modem data interfaces, filters unspecified and invalid nameservers before handing them to systemd-resolved, forwards non default DNS port numbers correctly, warns when DHCPv4 option 3 is ignored, and restricts certificate paths in private 802.1X profiles.
Point releases rarely deserve much attention. This one does, because the bug it fixes produces a support ticket that is almost impossible to diagnose from the description users give you.
The regression, and why it hides so well
NetworkManager 1.58 introduced a fault in how it handles WPA3 networks that use SAE, the key exchange that replaced the pre shared key handshake. Profiles configured with key-mgmt=wpa-psk stopped reconnecting automatically.
The reason this matters more than the version number suggests is that wpa-psk is how the overwhelming majority of profiles on real machines are written. WPA3 capable access points typically advertise both, and NetworkManager is supposed to negotiate the stronger option when it is offered, so nobody rewrote their profiles when SAE arrived. A regression targeting wpa-psk against SAE therefore hits almost everyone on a modern access point, not a niche configuration.
The failure mode compounds it. Manual connection still works. What breaks is the automatic path, so the report you receive is that Wi-Fi drops after a suspend, or after walking out of range, and that clicking the network fixes it. That reads like a driver problem, a power management problem or a flaky access point long before it reads like NetworkManager.
Version 1.58.1 restores automatic reconnection for those profiles.
The rest of the changelog
Several fixes here are worth reading even if you never touch WPA3.
On mobile broadband, IPv4 forwarding is now enabled on modem data interfaces. Connectivity checks also run when an interface has only IPv4 link scope default routes, which previously left some links marked as having no connectivity when they were fine.
On DNS, there are three distinct corrections. Unspecified addresses received as nameservers through RDNSS in IPv6 router advertisements and through DHCPv6 are now ignored rather than propagated. Invalid nameservers are skipped when configuring systemd-resolved, instead of pushing a configuration that will be refused. And a DNS URI carrying a non default port number now has that port forwarded correctly to systemd-resolved, which matters as soon as you run a resolver anywhere other than port 53.
On DHCP, NetworkManager now logs a warning when it ignores DHCPv4 option 3, the router option, because the lease also carries classless static routes without a gateway. That behaviour is correct and has not changed. RFC 3442 requires a client that understands classless static routes to ignore the router option when both are present. What has changed is that the client now tells you, which converts a silent surprise into a log line.
On profile handling, private 802.1X connection profiles now restrict ca-path and phase2-ca-path for connections that specify user permissions, so a per user profile cannot point certificate validation at an arbitrary directory. NBFT VLAN connections set their parent interface by name, which removes a boot race that could leave a network boot filesystem interface unconfigured. Bluetooth NAP connection normalisation is corrected, and several crashes found in 1.58 are fixed.
Should you upgrade
If you run 1.58.0 anywhere with wireless clients, treat 1.58.1 as a straightforward yes. It is a stable series point release, so the change surface is bug fixes rather than features, and the regression it closes affects the default way profiles are written.
If you are still on 1.56 or earlier, the decision is about 1.58 rather than 1.58.1. That release brought CLAT for IPv6 only networks, GENEVE tunnel support, work on the 6 GHz band, and the removal of the dhclient backend. Dropping dhclient is the item that needs planning if any of your profiles still pin it, so read the 1.58 notes before scheduling the jump.
What we would take from this
The general lesson is about profiles that outlive the standards they were written against. A key-mgmt=wpa-psk line written in 2018 is still there in 2026, quietly relying on negotiation to reach WPA3, and nothing in your configuration management flags it because it works.
That is fine until the negotiation path regresses, at which point the failure appears in the one place you are least likely to look: a configuration file everyone considers settled. If you maintain wireless profiles across a fleet, it is worth knowing which of them describe an older standard than the one they actually use.
Sources and further reading
- NetworkManager 1.58.1 Released with WPA3, DNS, and Modem Fixes, Linuxiac, August 21, 2026
- NetworkManager 1.58.1 Improves Support for Private Connections and Fixes Bugs, 9to5Linux
- NetworkManager 1.58 release notes, networkmanager.dev
Frequently asked questions
What was the WPA3 regression in NetworkManager 1.58?
A connection profile that specifies key-mgmt=wpa-psk would fail to reconnect automatically to a WPA3 network using SAE. The nuance is that wpa-psk profiles are supposed to work against SAE access points, because NetworkManager negotiates the stronger key management when the access point offers it. That is exactly how most existing profiles are written, since they predate WPA3 and were never rewritten. After 1.58 the first connection could still succeed while automatic reconnection did not, which produces a failure that looks intermittent and user specific rather than like a regression.
How do I tell whether I am affected?
Check two things. First, your NetworkManager version with nmcli --version or nmcli general, and whether it is 1.58.0 rather than 1.58.1. Second, whether your wireless profiles use key-mgmt=wpa-psk against an access point that advertises SAE, which nmcli connection show <name> will tell you under 802-11-wireless-security.key-mgmt. The symptom to look for is a client that associates when a user clicks the network manually but does not come back on its own after a suspend, a reboot or moving out of range and back.
What changed for DNS and systemd-resolved?
Three separate corrections. NetworkManager now ignores unspecified addresses arriving as DNS nameservers through IPv6 router advertisements (RDNSS) and through DHCPv6, rather than passing them along. It skips invalid nameservers when configuring systemd-resolved instead of handing over a configuration that will be rejected. And when a DNS URI carries a non default port number, that port is now forwarded correctly to systemd-resolved, which matters if you point clients at a resolver on anything other than port 53.
What is the new DHCP option 3 warning about?
NetworkManager now logs a warning when it ignores DHCPv4 option 3, the router option, because the lease also contains classless static routes without a gateway. This is standard behaviour: RFC 3442 says a client that understands classless static routes should ignore the router option when both are present. The problem was never the behaviour, it was the silence. Anyone who has spent an afternoon wondering why a DHCP supplied default gateway is not being installed will appreciate the log line.
Is 1.58.1 worth deploying immediately?
For anything running 1.58.0 on wireless, yes, because the WPA3 regression affects the most common way profiles are written. It is a stable point release: bug fixes and crash fixes from the 1.58 series, no new features to validate. If you are still on 1.56 or earlier, the more significant jump is 1.58 itself, which brought CLAT, GENEVE tunnel support, Wi-Fi 6 GHz work and the removal of dhclient. In that case read the 1.58 notes first, since dropping dhclient is the change most likely to need attention.