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
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
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
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
[Your editor would like to thank the Linux Foundation for funding his
travel to the event.]
to post comments)