Networking

Actual status

Network configuration with gnu tools under Linux mobile operating system is like a patchwork. Here works a script shooting someone elses script into the foot and if everything goes well you have a cleaned /etc/resolv.conf after the next reboot. While some tools bring references to /sbin/resolvconf with it (vpnc, ppp, …) others don’t (dhclient) but for those the resolvconf package brings the solution. The same goes for the resolvconf package where some scripts are contained in the package (for libc and bind) while others come from the packages itself (dnsmasq for example). This is a really, really ugly situation. If you work in quite a number of different networks your /etc/resolv.conf will be destroyed after the third switch for sure.

The GUI driven tools do not stop that crap. They are even build on top of all these tools which for example leads to wrong behavior and long times until the device is configured.

Good & Evil

Teamwork

The most important part is the correct nameserver configuration. Programs hang if there is a wrong one and this is predetermined if several scripts of various packages tamper around with the resolv.conf. The solution is simple: Have a local nameserver running, keep the resolv.conf pointing at that one and tell the local nameserver the real nameserver on the fly. Apparently there is a program that can do exactly that: dnsmasq. In its standard configuration you have to disable to read & poll the resolv.conf (because we dont change that one anymore) and other tweaks but mostly it works reliable out of the box. The nice feature here is that a new nameserver can be told to the daemon via dbus which makes changes easy.

Another part is retrieving the configuration information (if its not static) which is done via dhcp in most cases. As dnsmasq is controlable via dbus dhcp5 is not. dhcp5-dbus closes this gap.

The newer versions of the tool detect itself if a device gets ready (either by associating with an access point for wlan or by plugin in a cable). Tools like ifplugd and netplug are not needed anymore.

dhcp-like configuration is done by programs like ppp or vpnc also, we have to cope with them too. ppp is quite evil because its controlled by textfiles ([pap|chap]-secrets and the up/down scripts). I would prefere some arguments at startup or a dbus interface.

In case of a wlan setup wpasupplicant is the one to make this first step of connecting – which is equivalent to plugin in the ethernet-cable.

i’m currently not sure wether udev has a role in all this. i currently use it to distinguish different devices plugged into by determining the mac of the usb-ether connected neo like described here.

More issues: I am also interested in other issues like automatic proxy or even smarthost (smtp) and printer (i don’t use cups, lprng rules) configuration. Also some weird wireless networks need some (for example http based) authentification which should be automated by a shell/curl script.

Suggestion

Step 1: connectivity detection

Either by plugging in a cable, by successfully joining a wireless network or by the outcome of ppp’s lcp we have a connection.

Step 2: determine ip / defaultroute configuration

ppp and vpn have an own mechanism to determine these settings. wlan and ethernet will be watched by dhcpcd5. this daemon is able to detect the event and start configuration.

Step 3: nameserver configuration

A local nameserver daemon is running (dnsmasq) and /etc/resolv.conf will point to it. this file will never ever be changed (i use `chattr +i` to circumvent that for crappy packages).

dnsmasq will be informed of the current nameserver via dbus. I wrote a script, named it /sbin/resolvconf that does this trick. Its acting the same way as that same script from the resolvconf package (reading config in /etc/resolf.conf syntax from standard-in, accepting parameter ‘-a dev’ and ‘-d dev’ but calculating the config to be fired into dnsmasq). See pyneo-resolvconf for the source. The script is automatically used by dhcpcd5.

Step 4: smarthost (email) configuration

Step 5: proxy (http) configuration

Step 6: printer configuration

Step 7: tethering (forwarding) configuration

Implementation:

• debian’s insserv determines a wrong order of initing/starting daemons for this setup. The Required-Start/Stop has to mention dbus in /etc/init.d/dnsmasq.
• dnsmasq.conf must contain the following options (different from the ones delivered with debian):

  no-resolv
  no-poll
  enable-dbus
  clear-on-reload
  domain-needed

• List some devices to be not watched by dhcpd in /etc/dhcpcd.conf

  denyinterfaces ppp* tun* pan* irda*
  

• Someone has to switch on the device ‘lo’ which is normally done by ifupdown. i put a line into /etc/init.d/networking solving t

  if [ ! -x /sbin/ifup ]; then
  	ip link set lo up
  	exit 0
  

Drawbacks:

This proposal is lacking the following features:

• dnsmasq’s dbus implementation does not answer method calls so calls are more “fire and forget” calls, there is no error detection if the call was successful not even a non-running dnsmasq can be detected.
• No solution for non-dhcp network setups.
• No avahi/mdns magic stuff support.