NetworkManager 1.8: What’s new

Three and a half months (and some 700+ commits) after NetworkManager 1.6, we’re pleased to announce NetworkManager 1.8 is ready. This release is generally focused on fixing bugs and addressing usability annoyances, yet it delivers some new features as well. Let’s have a look!

Reliable daemon restarts

In general, NetworkManager is not something that is restarted too frequently. But when it is, chances are it will end up looking slightly confused. In particular, a different connection profile may appear to be active on a device than before the restart.

There is a reason for this. NetworkManager tries to leave the network interfaces configured on shutdown. This is done to prevent unpleasant surprises in the form of broken remote shell sessions or even network mounts.

On daemon restart, we’d like to pick up the existing configuration. The problem is that we don’t just want to pick up any existing configuration — we do out best not to mess up with the configuration created outside NetworkManager. We’ve ended up with a rather complicated heuristics to determine the connection profiles that could be active. As it turned out, it was possible to end up in an ambiguous situation where our guess didn’t match the situation prior to the restart.

With NetworkManager 1.8 we’ve gotten rid of the guesswork. We save the runtime state to a file on shutdown and pick it up on startup, bringing the ambiguity to an end.

Better connectivity checking

NetworkManager periodically attempts to access a pre-configured web page in order to determine whether the host is able to access the Internet using its “best” default route. This is used to detect “captive portals” — typically wireless routers that hijack connectivity for the purposes of network authentication so they could be dealt with in secure manner (they would often attempt to do ill-advised tricks, such as hijacking secure connections, practically conducting man-in-the middle attacks).

In NetworkManager 1.8, connectivity checks are done for all connections with a default route. This allows us to do neat things, such as penalize connections that fail the check with a higher route metric. The practical consequence is that a wired connection that has a default route, but no Internet connectivity will have a higher metric (and thus a lower priority) than simultaneously active Wi-Fi connection that is connected to the Internet.

Aside from that, the connectivity checking now utilizes libcurl instead of libsoup, resulting in smaller dependency chains in typical small installations.

…and a lot more

We’ve made nmcli better: it is now easier to use in scripts and provides better error handling. NM now supports setting attributes for static routes. The dependency chain is smaller with libgudev no longer being required and libsoup being replaced by libcurl. Support for mobile broadband devices, team devices, bonds, dummy links, SR-IOV capable devices have all seen improvements. More control over hostname update is now allowed.

If you’d like to check for yourself, read the NEWS file or grab the new release!