The NetworkManager team just released NetworkManager 1.2, and it is the biggest update in over a year. With almost 3500 commits since the previous major release (1.0), this release delivers many new key features:
- Less dependencies
- Improved Wi-Fi and IPv6 privacy
- Wider support for software devices
- Improved command line tool
- Better documentation
- Support for multiple concurrent VPN sessions
Let’s have a closer look!
Improved privacy
We take everyone’s privacy very seriously. That is why we’re among the first adopters of RFC7217 that addresses the problem of tracking a host that moves between IPv6 networks. Users can read more about this in a separate article.
The identity of a mobile host can also leak via Wi-Fi hardware addresses. A common way to solve this is to use random addresses when scanning for available access points, which is what NetworkManager now does (with wpa_supplicant 2.4 or newer). The actual hardware address is used only after the device is associated to an access point.
For further privacy, users can enable Wi-Fi hardware address randomization while connected to untrusted access points, though this is not the default behavior as it may cause issues with access control policies and captive portals.
Better Wi-Fi
In addition to Wi-Fi privacy improvements, Wi-Fi scanning is much smarter and more responsive. The access point list is now maintained by wpa_supplicant and doesn’t grow insanely large when the device is moving, and the currently associated access point is more accurately detected. Dan’s blog covers the change extensively.
Mobile users will appreciate that we’ve added the possibility to enable Wi-Fi power saving globally or on a per-connection basis.
Support for software devices
NetworkManager already supported creation of bond, team and bridge devices. With version 1.2 users can also manage tun, tap, macvlan, vxlan and IP tunnel devices.
Improved command-line experience
Our command line client is now friendlier and more flexible than ever before. It uses colors to match the status of a device or a connection and sorts the output for better clarity.
Users can specify arbitrary connection properties at creation time, without the need to create a connection first and edit it afterwards.
We also simplified creation of master-slave relationships between devices, making it easy to enslave any kind of device to bridges, bonds or teams. Creating multi-level stacking of devices is now very easy.
Use of VPN connections with nmcli is now a lot better too; see below.
We have a very good command completion rules for Bash and excellent manuals with examples too.
Slimming down
With NetworkManager 1.0 we’ve split some hardware support into loadable modules. This makes sense on server or minimal installations — e.g don’t need containers to support Wi-Fi, or servers to run Bluetooth. For NetworkManager 1.2 we’ve cut down on external libraries.
The use of dbus-glib has been replaced with gio’s native D-Bus support and libnl-route-3 is no longer used. Dependency on avahi-autoipd has been dropped.
Native IPv4 link-local addressing configuration based on systemd network library is now used instead.
Users running NetworkManager from minimal images, such as in small systems or containers, are going to benefit from this release too: NetworkManager runs just fine in LXC containers or even Docker. For further details please take a look at readily made Docker images with NetworkManager.
Finally, we don’t manage the hostname by ourselves anymore on systemd-based systems — if anyone uses our, now deprecated, API for hostname management, we just forward it to systemd-hostnamed which is a lot better at the job.
More flexible VPN support
The VPN support has been improved considerably too. Before NetworkManager 1.2 users could only run one instance of a particular VPN plugin that would service exactly one connection. This limitation is now gone.
It is now also possible to connect to a VPN from the command line using nmcli. If the VPN needs a password, nmcli will ask when the user use the –ask option.
Finally users can now import and export the VPN connection settings of most types of VPNs in the VPN’s native format from the command line using the nmcli connection export and nmcli connection import commands.
…and a lot more
NetworkManager gained a lot more than could be reasonably described here. There’s support for configuring the Wake-on-LAN capability of Ethernet hardware, a LLDP listener, better resolv.conf management and more. Take a look at our NEWS file for details.
This release wouldn’t be possible without community contributions. Over 50 people contributed to the NetworkManager code base and a lot more contributed bug reports. Without them we’d have hard time figuring out which parts of NetworkManager needs our attention and care.
Thanks to Beniamino Galvani, Thomas Haller, Dan Williams, Francesco Giudici and Rashid Khan who contributed major parts of this article and corrected many mistakes.
Hi!
Is it still possible to run nm without systemd?
Thanks!
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
We definitely don’t need systemd in runtime. Gentoo seems to run NetworkManager without systemd happily. They still rip off some parts of systemd (udev and consolekit2), but it probably works for them.
That said, if your distribution doesn’t ship systemd you’re probably missing out of the good stuff that comes with it. You probably are aware.
Gosh, I want Network Manager 1.2 in RHEL so badly. Great job!
I don’t think it’s a secret that RHEL 7.3 will indeed ship with 1.2 or a later version.
I’m looking forward to seeing NetworkManager 1.2 in RHEL 7.3, for sure!
Speaking of VPNs, OpenVPN’s import sucks. It can only correctly import credentials (yet not automatically choose the option) and gateway address. I need to manually extract the key from the .ovpn file into a .cert one and then specify it. And if I accidentally misplace the .cert, the connection won’t work. What’s even the point of having the import option for OpenVPN if it doesn’t actually do it? I hope it’s been fixed.
And the commonly available option across platforms, L2TP/IPsec is missing altogether. Third-party plugins doesn’t even support PSK.
We’ve made it a bit better. I think for NetworkManager-openvpn 1.2.0 we support inline certificates?
We have NetworkManager-libreswan for IPSec with IKEv1; that one surely supports PSK. There’s also NetworkManager-strongswan which supports IKEv2 with PSK, EAP and certificates. It’s going to get an update very soon (in review now).
Status of L2TP is mostly unknown. There’s a plugin, but there seems to be too little community interest in it; we often don’t get any feedback for the updates. If you’d like to help, please let us know.
Yes, it imports keys very well. It does not import key direction though (based on what is shipped with ubuntu 16.04).
I meant that it imports inline keys very well.
What do you mean by “in review now” ? strongswan doesn’t seems to be compatible with NM 1.2 and there’s no release since sept. 2015 …
We’ve added NM 1.2 support, but Strongswan upstream doesn’t seem to be completely happy with it. It needs more work, but we’re sort of low on manpower. For now we have to recommend using Libreswan instead if possible, that one is has better support. We’ll appreciate help with fixing the Strongswan very much.
See: https://github.com/strongswan/strongswan/pull/15
Thanks so much for your work, this is awesome software!
With all the shiny systemd integration added, does it also use `systemd-resolved` for DNS handling now?
On our roadmap!
Can I share my internet connection with others using GUI? I just can’t figure out how to share eth0 over wifi with friends in GNOME.
Not sure. You can certainly create a “Shared” connection via nmcli or nm-connection-editor.
GNOME has “Hotspot” functionality, but that probably only works with Wi-Fi. 🙁
Thanks, a really great, well written post.
It would be great if the RHEL tool “nmtui” were part of the official NM suite.
It indeed is and is by no means RHEL specific.
In fact, everything RHEL ships is in the upstream NetworkManager first!
Instead of “Dan’s blog” the link given points to one of your own posts. Is this intended to be so?
I enjoyed very much reading this post to familiarize myself with the great changes brought by Network-Manager 1.2.
The link to Dan’s blog in the section “Better Wi-Fi” points to an unrelated (in the “Better Wi-Fi” section) post by Lubomir. The correct link, while Lobomir fixes the post, is:
https://blogs.gnome.org/dcbw/2016/01/18/networkmanager-1-2-has-better-wi-fi-scanning/
Cheers!
On Ubuntu 13.10 and 14.04 using the KDE desktop, I found network manager so flaky that I switched it out for WiCD and never looked back. It was immediately an improvement in the GUI and in the reliability of the network, with nothing else changing but the switcheroo.
Do you think this new Network Manager version 1.2 is reliable enough to give WiCD a run for the money?
The one critical security feature neither nm had nor did WiCD is an option to immediately shut down connection to the WiFi card if the VPN tunnel drops.
Is that mandatory security feature enabled with the new network manager?
Microsoft’s Windows 10 Mac Address randomisation strategy seems pretty good.
https://huitema.wordpress.com/2015/12/31/mac-address-randomization-in-windows-10/
Any plans for WPS push-button configuration?
Yes, but it’s low priority — not in 1.4. WPS is known to be broken and insecure.
That said, we’d very likely accept patches to use it. We’d most likely need to make sure the user knows what is he doing.
Something I’ve noticed and never bothered to properly investigate is that when I use the openconnect CLI and the underlying network connection drops, it will keep trying to restore the VPN connection. NetworkManager drops the VPN connection and I have to re-authenticate and rejoin IRC (because my IP address changes)
Thank you very, very much for caring about privacy!
Awesome! 🙂 I can barely wait to play with NM 1.2. Hopefully Ubuntu 16.04 will have the packages soon enough.
Is it possible to block some WIFI networks for automatic connections (say: generally set autoconnect, but not for WIFI network with name “ICE” or “T-Mobile HotSpot”)?
Background:
Those networks push a dial-in page at first.
If you’re booting in a mobile environment (e.g. on a train) connection is established before logon to Linux is completed,
and the package manager (i.e. apt-get of Linux Mint in my case) is trying to update packages. The dial-in page destroys current package lists. That’s quite annoying, and I’d like to prevent this.
Yes. There’s “Connect Automatically” button in the connection editor.
Is there someway to fix the mac-address of a bond/team interface, so that it doesn’t depend on what order the slaves got activated ? Setting cloned-mac-address on the bond/team connection is not working.
Is this even a NM issue or a kernel issue ?
Turns out this was bug in teamd not NM (https://github.com/jpirko/libteam/commit/c18a6349a7bd0a2d41d0193128b95a520479591f)