NetworkManager 1.2 is here!

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.

Published by

Lubomir Rintel

A free software enthusiast, Fedora contributor and a NetworkManager developer.

32 thoughts on “NetworkManager 1.2 is here!”

  1. Hi!
    Is it still possible to run nm without systemd?
    Thanks!

    [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

    1. 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.

  2. 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.

    1. 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.

      1. 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 …

  3. 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.

    1. 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. :(

  4. 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?

    1. 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.

  5. 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)

  6. 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.

  7. 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 ?

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *