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!