User:Pavlix

I have been using Fedora for some time. My primary interest is computer networking and I didn't like many things in linux networking and particularly in NetworkManager. I've been talking about it and watching and filing bug reports for too long. When I recieved an offer to work regularly on NetworkManager, it was natural to accept.

At the time I joined NetworkManager development, I already had a history of articles, talks and trainings on IPv6 so I started fixing IPv6 automatic configuration. In NetworkManager 0.9.6 it connects to any standard IPv6 networks.

I didn't particularly like how NetworkManager works so after learning a bit about it, I started working on some larger-scale changes in a separate branch called 'pavlix/next' that is described below. All of the modifications are made with the goal of making NetworkManager more robust, testable, debuggable and useful for all sorts of use cases including server, virtualization and desktop.

During my work on NetworkManager, I see more and more problems with other network-related tools including kernel, glibc, avahi, nss-mdns but also with the IETF standards. We have many more things to be fixed (or replaced, if anyone likes that better) than just NetworkManager.

What we need for proper Linux networking

• Interface for static IPv4 and IPv6 configuration (kernel)
• Interface for bridging/bonding/vlan configuration (kernel)
• Interface for DNS configuration (/etc/resolv.conf)
• DHCP client implementation for IPv4 automatic configuration (dhclient)
• RA client implementation for IPv6 address configuration (kernel, with workarounds in NetworkManager)
• RDNSS/DNSSL client implementation for IPv6 DNS configuration (NetworkManager through kernel, with workarounds)
• DHCP client implementation for IPv6 address/DNS/other configuration (dhclient)
• IPsec, VPN and tunneling implementations (various daemons)
• A network management daemon to properly manage all of the above together with user configuration (NetworkManager)
• Networking API for applications (glibc, with many problems)

I may have missed something but the objective is to show that networking is rather complex and the various tools need to be centrally managed by a network management service in order to make users and administrators happy.

You can only live without network configuration daemons if you use static IP configuration and you avoid encrypted wireless networks at the same time. You can live with just wpa_supplicant and dhclient only if you are used to do most of the stuff yourself. Virtually all linux distributions now converge to network solutions based on network configuration daemons.

Examples of such daemons (without feature comparison):

• NetworkManager
• connman (MeeGo)
• WICD
• netifd (OpenWRT)
• netcfg (Archlinux)
• wicked

Yeah, it's a lot of fun writing new and new network configuration daemons.

NetworkManager

When working on NetworkManager, the following projects cause me headache:

• NetworkManager itself: I need to test NM in a virtual environment with bridges. These are not supported in the current release. I hope to make the next release mature enough to support its own development.
• Kernel: The kernel IPv6 networking layer is somewhat unmanagable. The rtnetlink interface doesn't provide enough funcionality to support IPv6 networking.
• GLIBC: The getaddrinfo() function doesn't work properly and is not supported in nsswitch.conf. It breaks whenever my development machine happens to be on an IPv4-only network.
• nss-mdns (Avahi nsswitch plugin): Can't implement link-local name resolution because of the above problem in GLIBC.
• IETF networking standards: For some reasons many IPv6-related standards have serious design flaws that prevent them from working properly.

I'm currently maintaining a patchset in a separate NetworkManager branch called 'pavlix/next'. It has a lot of improvements over the current release of NetworkManager but also over the 'master' branch. The reason for keeping a separate branch is that I need to do a lot of interdependent stuff to fullfil a big picture of how things should work. Many changes I'm making are quite big.

I am often rebasing this branch and rewriting its history. It is not currently possible to merge it into 'master' and it is not possible to continuously marge your local changes without a considerable amount of 'rebase' magic.

The current patchset includes the following changes:

• Add a new subsystem for kernel network configuration (bgo #683173)
• Remove distribution-specific initscripts
• Build on any linux distribution without special options (bgo #663602)
• Remove unnecessary '--with-distro' values (some distributors may need to remove it from their package builds)
• Move NM-specific DHCP leases to /var/lib/NetworkManager (may need selinux policy changes)
• Add support for IPv4 dhclient.conf overrides in /etc/NetworkManager
• Don't ask 'nscd' to reload configuration (it uses inotify to watch it)
• Add support for bridges with manual and automatic IPv4/IPv6 configuration (bgo #546197)
• Fix support for bonds with manual and automatic IPv4/IPv6 configuration (bgo #540995)
• Read IPv4 addresses also in CIDR format in keyfile

Other stuff:

• I'm trying to keep NetworkManager bugzilla (at least the 'general' component) in a good state
• I fixed various IPv6-related so that IPv6 autoconfigures in all common scenarios

GLIBC

• getaddrinfo(127.0.0.1, AI_ADDRCONFIG) fails on hosts without global IPv4 (e.g. notebooks not connected to any networks)
• getaddrinfo(::1, AI_ADDRCONFIG) fails on hosts without any other IPv6 address
• getaddrinfo(link-local-address, AI_ADDRCONFIG) fails on hosts without global IPv6 (hopefully solved)

Temporary patch: https://bugzilla.redhat.com/attachment.cgi?id=615840

IETF standards

• RFC 6106 (RA DNS): Relies on a false assuption that every (even multicast) IP packet is delivered to its destination.
• RFC 4861 (NDP): Doesn't specify how zero lifetimes should be used and lets implementations rely on the same false assumption.
• RFC 3493 (socket interfce): Breaks both IPv4 and IPv6 localhost and link-local networking depending on available global addresses.

Proposed features

• Features/DualstackNetworking

Contact

Mail: psimerda AT redhat DOT com, pavlix AT pavlix DOT net

Jabber: pavlix AT pavlix DOT net

IRC Freenode: pavlix (#nm and a couple of other channels)

Phone: +420 775 996 256