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.
<figure class=”wp-caption aligncenter” id=”attachment_132″ style=”width: 419px”><figcaption class=”wp-caption-text”>Debian 9 snapshot already includes the new, much faster, nmcli</figcaption></figure>
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.
For more details, watch this talk by Sabrina of Red Hat, who implemented the kernel and wpa_supplicant parts.
Faster client library and tools
I mean really faster. Check out the D-Bus timing diagram. Behind the speedup is the rework of the client library to utilize the org.freedesktop.DBus.ObjectManager API. It allows us to initialize libnm in constant time. What we couldn’t initialize using the ObjectManager we made parallel.
In practical terms this means “nmcli c” would be a lot snappier even with a lot of connections or devices. This also significantly reduces latency where good interactive response is needed, such as when tab-completing the connection names.
Really, try it!
Support for systemd-resolved
Here’s some good news for those, who have systemd-resolved in charge of their name resolution: NetworkManager now integrates with it seemlessly. That means it tells it about the domain servers as they are discovered. To make NetworkManager not to control your resolv.conf directly, it’s sufficient set the “dns” property in your NetworkManager.conf file.
Web Proxy support
NetworkManager now supports configuration and discovery of Web Proxies and hands over the information to PacRunner. PacRunner then does the heavy lifting of interpreting the WPAD scripts and providing a sane interface to whichever application wants to use a proxy.
It should be noted that this feature as developed by Atul, a newcomer to NetworkManager developer community. He did the work as part of Google Summer of Code project and he has done a superb job. Proxy users will notice.
IPv6 Connection sharing
2016 was the year IPv6 continued to grow exponentially and almost doubled. Therefore we decided it’s time to extend the IPv4-based connection sharing typically utilized by the Wi-Fi Hotspot feature with a IPv6-based counterpart. Unlike IPv4 that uses private address ranges and NAT for the downstream network, the IPv6 connection sharing utilizes RFC 3633 DHCPv6-based Prefix Delegation.
This means that the downlink connection gets a globally routable address, but it also requires your router to provide you with a prefix to use. We don’t have plans to support NAT for IPv6 on our roadmap — with growing importance of IPv6 it’s important that everyone gets their IPv6 setup right. We’d love to hear about your experience with IPv6 and the connection sharing in the comments.
Note: for now the feature only works with the ISC DHCP client and is known not to play very well with OpenWRT/LEDE’s odhcpd. We’re working with the odhcpd developers to address that.
We’re almost done with NetworkManager 1.8; we just need iron out some rough edges. What’s coming is smarter connectivity checks, better PKCS#11 integration or much smaller dependency chain. But that’s going to be covered in the next article.