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?
If your corporate VPN access is via a Fortigate appliance’s proprietary SSL VPN there’s chances you’re using the vendor provided client. Too bad that one doesn’t really plug into modern Linux desktop experience; it’s CLI only and you’re not able to customize the network configuration too much. There’s no source code and thus no way you’ll be able to do anything about it.
With the availability of the new VPN plugin NetworkManager-fortisslvpn we address this. On its backend it uses the free software protocol implementation openfortivpn (thanks to Adrien Vergé) that got some major improvements lately and integrates well with NetworkManager.
Both openfortivpn and the NetworkManager-fortisslvpn plugin will be available in Fedora in next few days; the other distributions will hopefully follow.
New major version if NetworkManager, a service that manages your network connectivity is being released in coming months. This might be a good time to talk about the changes you can expect.
A simple client tool has been introduced with the release of NetworkManager version 0.8.1. Since then it has improved to the point it’s able to configure all functionality provided by the service. It can be used to control the daemon, manage the connections and create complex network configurations.
It’s accompanied by extensive documentation in nmcli(1) and nmcli-examples(1) manuals. Since the big overhaul in 0.9.10 release, we’re keeping the format of command line arguments compatible, guaranteeing your scripts that use it will keep working. Nevertheless, we’ve made some changes that make it easier to use.
Compared to the previous release it’s a rather small release, weighing just a little short of 160 commits. Nevertheless, we’ve included a fair amount of fixes and improvements from both the NetworkManager Team and the community.
While the stable series is mainly focused on improving robustness we’ve added some features too, making NetworkManager a bit more flexible and easier to use:
Improved capture portal detection. The capture portal now understands the RFC6585 HTTP 511 status code.
Default route through WiFi connection is now preferred to Mobile Broadband if both are available.
We now expose information on whether a particular connection is metered. It’s intended for tools like package managers that like pre-fetch large amount of data to be able to avoid increasing your Mobile connectivity bills.
NetworkManager can now configure Wake-on-LAN capabilitites of Ethernet hardware.
The release will likely find its way to your distribution’s mirror near you soon. It’s queued for Fedora 23 that’s expected to arrive later this year and also available in Fedora 22 testing repository, Other distributions will likely follow soon.
There’s more exciting features coming with NetworkManager 1.2 later this year. Stay tuned!
We recommend everyone to update and will appreciate any feedback!