LCE: Challenges for Linux networking

It's common to think of networking as being essentially a solved problem for Linux. But, like the rest of the computing environment, networking is evolving quickly over time, and Linux will have to evolve with it. Marcel Holtmann used his LinuxCon Europe slot to talk about some of the work that is being done to ensure that Linux networking remains second to none.

In particular, Marcel is concerned with improving networking on mobile devices. He is staying away from enterprise networking, which, he said, is pretty well worked out. It's mostly based on cabled connections with "no crazy stuff" to worry about. But mobile networking is different. The environment is far more dynamic, there is much more user interaction involved, and there is a long list of tools needed to manage it — and many of those tools are old and not up to the task.

That said, some of the problems are nicely solved at this point. The "networking basics" are in place; these include Ethernet and WiFi support, along with Bluetooth, cellular protocols, and higher-level protocols like DHCP, DNS, and NTP. IPv6 support is mostly there, and tethering support is now in good shape. We also have the beginnings of support for the WISPr protocol which enables automatic login to wireless hotspots. Things are quite good, Marcel said, for the simpler use cases.

The problem is that, increasingly, the common use cases are not so simple, so there are a number of challenges to be overcome before Linux can take the next step. The first of those is being able to answer a simple question: is the system actually online? Simply being associated with an access point is often not enough if that access point requires authentication. It is not an uncommon experience to have a smartphone hook up to an access point with a recognized SSID and, since the authentication step has not yet happened, lose connectivity entirely. The problem is that, at this point, there is no easy way to know if a system is actually on the net or not.

An additional complication is the concept of a locally-connected network; a mobile device may be connected to local devices (a television, say) without having access to the wider Internet. We don't currently have a way to detect that situation or to communicate it to applications.

Connectivity is currently thought of at a global level — the system is either online or it is not. But different applications have different connectivity needs, so we need to move toward a concept of per-application connectivity. The system should be able to go online for a specific task (synchronizing an important application, say) without necessarily opening the floodgates for any other application that may want to talk to the world. We currently have no way to do that because Linux networking is based around systems, not around applications.

An additional irritation is that, once connectivity is established, all applications are notified of the availability of the net at the same time. That creates a sort of thundering herd problem where a whole range of processes try to open connections simultaneously. The result can be a clogged link and frustrated users. We really need a one-at-a-time waking mechanism for applications, with the more important ones being notified first.

There is a real need for finer-grained usage statistics for the net; currently all statistics are global, which tends not to be helpful in the mobile environment. There are no per-user or per-application statistics, and no way to distinguish home-network traffic from roaming traffic. Android has a solution of sorts for this problem, Marcel said, but it is "a horrible nasty hack" that will never make it upstream. Somehow we need to come up with a cleaner implementation.

Time is simple in the data center; one just has to fire up NTP and forget about it. But it is a more challenging concept on a mobile system. Those systems can move between time zones; it can be hard to know what time it actually is. For added fun, many of the available sources of time information — cellular networks, for example — are often simply wrong. So the system needs to find a way to look at data from multiple sources before concluding that it is safe to change the current time zone.

Time confusion can also create trouble for applications, especially those with complex synchronization requirements. To avoid problems, the system really needs to figure out the correct time before notifying applications that the network is available.

The concept of network routing must become more sophisticated in the mobile environment. Some applications, for example, should only be run if the virtual private network (VPN) is available, while others can run over any network. Other applications should not be allowed to use the VPN regardless of its availability; the same is true of Bluetooth and other types of connections.

If a WiFi connection becomes available, some applications may want to use it immediately, but an application in the middle of a conversation over the cellular connection should be allowed to wrap things up before being switched to the new route. So there needs to be something like per-application routing tables, something that a tool like ConnMan can change easily, but, Marcel said, the current network namespace implementation is too strict.

What bugs Marcel the most, though, is the Linux firewall mechanism. He wants to be able to set up personal firewalls that differ based on the current location; a configuration that works at home or in the office may be entirely inappropriate in a coffee shop. He didn't have much good to say about the Linux firewall implementation; it's highly capable, but impossible to configure in a reasonable way. There are, he said, lots of race conditions; reconfiguring the firewall involves clearing the old configuration and leaving things open for a period. He is hoping for a conversion to nftables, but progress on that front is slow.

Marcel would also like to see the easy creation of per-application firewalls; just because a port is opened for one application does not mean that others should be able to use it.

Local WiFi networks, for applications like sending video streams to a television, are coming. That requires support for protocols like WiFi Direct. The good news is that the kernel has fairly nice support at this point; unfortunately, the user interface work has not been done. So only expert users can make use of this capability now. Making it work properly for all users will require a lot of integration work into a lot of subsystems, much like full Bluetooth support needed.

Speaking of Bluetooth, it now has support for pairing via the near-field communications (NFC) protocol. Essentially, devices can be paired by touching them together. NFC-based authentication for WiFi access points is on its way. There is also work being done to support sensor networks over protocols like 802.15.4 and 6LoWPAN.

To summarize the talk, there is a lot of work to be done to provide the best mobile networking experience with Linux. Happily, that work is being done and the pieces are falling into place. Lest anybody think that there will be nothing for anybody to complain about, though, it is worth noting an admonition that Marcel saved for the very end of the talk: in the future, the use of systemd and control groups will be mandatory to get good mobile networking with Linux.

[Your editor would like to thank the Linux Foundation for funding his travel to the event.]

---

(Log in to post comments)

$ cat /etc/pdns-recursor/recursor.conf
setuid=pdns-recursor
setgid=pdns-recursor
local-address=127.0.0.1
dont-query=127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, ::1/128
forward-zones-file=/etc/pdns-recursor/forward_zones
$ cat /etc/pdns-recursor/forward_zones
local=10.7.96.21
10.in-addr.arpa=10.7.96.21
$ cat /etc/resolv.conf
nameserver 127.0.0.1
search local