Another three months have passed since NetworkManager’s 1.18, and 1.20 is now available. What follows is a quick overview of what’s new.
We’re dropping some old cruft
Yes, the line diff compared to the previous major release, NetworkManager 1.18, is negative!
The libnm-glib library, deprecated in favor of libnm since NetworkManager 1.0 release almost five years ago, was dropped. At this point it’s almost certain to have no users.
If you’re developing a program that has anything to do with network configuration, libnm is the way to go. You can also use it from other languages than C via GObject instrospection — just check out our examples.
NetworkManager needs no introduction. In fifteen years since its initial release, it has reached the status of the standard Linux network configuration daemon of choice of all major Linux distributions. What, on the other hand, may need some introduction, are the features of its 28th major release.
Ladies and gentlemen, please welcome: NetworkManager-1.16.
Guarding the Wire
Unless you’ve been living under a rock for the last year, there’s a good chance you’ve heard of WireGuard. It is a brand new secure protocol for creating IPv4 and IPv6 Virtual Private Networks. It aims to be much simpler than IPsec, a traditional protocol for the job, hoping to accelerate the adoption and maintainability of the code base.
Unlike other VPN solutions NetworkManager supports, WireGuard tunnelling will be entirely handled by the Linux kernel. This has an advantages in terms of performance, and also removes the needs of a VPN plugin. We’ve started work on supporting WireGuard tunnels as first-class citizens and once the kernel bits settle, we’ll be ready.
A brand new version of NetworkManager, a standard Linux network management daemon, is likely to reach your favourite Linux distribution soon. As usual, the new version is 100% compatible with the older releases and most users can update their systems without spending much time caring about technicalities.
Nevertheless, we’ve spent significant effort improving things under the hood, addressed many bug reports and added new features. We are especially proud of the increased community contributions to NetworkManager.
Read on to learn what awaits you in the version 1.12!
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.
NetworkManager 1.6 was delivered in early 2017, and is doing pretty well. It has found its way to many Linux distributions, including the upcoming Debian 9 “Stretch” release. There are good chances you’re already running it. Nevertheless, we still owe you an overview of what’s new.
My favorite parts are: MACsec, much improved libnm performance, systemd-resolved support, PacRunner integration and IPv6 connection sharing. Let’s delve into them!
When accompanied with a recent-enough wpa_supplicant (that for now means a post 2.6 git snapshot) and kernel (4.6 or newer), NetworkManager is able to create and maintain IEEE 802.1AE (better known as MACsec) links.
For those those who don’t know: MACsec is an encryption protocol that operates in the data link layer (Layer 2 in OSI model), beneath IP. MACsec comes useful when you don’t trust your physical link — such as with cloud hostings. IPsec, on the contrary, would operate on Level 3 and thus is not practical for protecting the ARP, DHCP or Neighbor Discovery traffic.
After we released version 1.0 of NetworkManager, it took us sixteen months to reach the 1.2 milestone. This means that it took over a year for some newly added features to reach the user base. Now we are releasing the next major release after just four months.
This improved release cadence was made possible by the excellent work of Red Hat’s Quality Engineering team during the development cycle. Their thorough testing gave us confidence in the new code and dramatically lowered the number of bugs late in the release cycle.
Despite a somewhat shorter release cycle the new version of NetworkManager, while still API and ABI compatible with previous versions, is by no means short on improvements. Let’s take a detailed look!
The central component of good modem support on Linux is ModemManager. The components, such as NetworkManager, that make use of modems in Linux would typically use the convenient D-Bus interface ModemManager provides.
Nevertheless, there’s more to good modem support than just ModemManager. There’s little standardization in the protocols that modems use and multiple components need to coordinate to support a wide range of hardware with all of its idiosyncrasies.
There’s more to good modem support than just ModemManager.
This article will provide a short overview of the modern Linux modem support stack and some recent changes to it. If you own a modem, we may need your help to ensure it’s well supported. Read on to find out how can you help!
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:
It’s quite some time since we’ve done an update to the 1.0.x version. As it matures, we’re busy getting the 1.2.x tree ready for release. Nevertheless, fixes waiting to be delivered have accumulated over the time, so we’re releasing them now.
The new version fixes a number of issues, such as
a crash in Wi-Fi management that has been bothering users according to the volume of ABRT bug reports,
ordering of the NetworkManager.service in systemd-managed distributions
a low severity race condition that could cause a leak of connection secrets (Wi-Fi password) to a local authenticated user
bad behavior when another tool created a Wi-Fi monitor mode interface
If your distributor ships NetworkManager 1.0.x, you can probably expect an update soon. Fedora 23 users can grab the new release from the updates-testing repository, Fedora 24 testers already run a 1.2.x snapshot.
PS: Thanks for responses to the user survey. It’s very valuable to us. We’re reading every single of the 1500 responses, so it may take time till we respond to yours. Thanks for the patience.
Recently, while considering possible improvements to our command line client, we realized that we’re not really confident about how useful is it for the users. Do you use it? Is it intuitive enough? Do sysadmins like it? Is the documentation all right? Do we communicate features sufficiently?