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?
The mobile computing is on a steep rise for over a decade now and so is the always-on networking. You probably have a networked phone in your pocket now, carry a laptop and maybe a tablet computer, all connected to the Internet.
With the availability of the wireless networks, mobile networking is easier than ever. What’s also easier than ever is violating one’s privacy. Even when you’re super careful about encrypting your Internet traffic, the meta-data can leak enough information to make you worried.
What’s also easier than ever is violating one’s privacy.
IEEE, the standard body behind the Wi-Fi specification, set up a study group to cope with the problem and the industry starts coping with the problem as well. Let’s have a more detailed look!
IPv6 is gaining momentum. With growing use of the protocol concerns about privacy that were not initially anticipated arise. The Internet community actively publishes solutions to them. What’s the current state and how does NetworkManager catch up? Let’s figure out!
The identity of a IPv6-connected host
The IPv6 enabled nodes don’t need a central authority similar to IPv4 DHCP servers to configure their addresses. They discover the networks they are in and complete the addresses themselves by generating the host part. This makes the network configuration simpler and scales better to larger networks. However, there’s some drawbacks to this approach. Firstly, the node needs to ensure that its address doesn’t collide with an address of any other node on the network. Secondly, if the node uses the same host part of the address in every network it enters then its movement can be tracked and the privacy is at risk.
Internet Engineering Task Force (IETF), the organization behind the Internet standards, acknowledged this problem and recommends against use of hardware serial numbers to identify the node in the network.
But what does the actual implementation look like?