Comment 23 for bug 1587808

So... a long time ago, when Ubuntu Touch was first being developed, we hit a bug with certain rild implementations that would configure the routing table when a data call was established, and this caused problems with NM's routing logic.

The workaround was the creation of a NM dispatcher script called 02default_route_workaround, which runs the following command when triggered:

ip route flush proto boot

This clears any pre-existing routes, and let's NM be the master of the routing table. As you can imagine, this doesn't play well with externally managed devices which may have created default routes.

I confirmed that this script was the culprit by adding a logger statement to log when the script gets called to syslog. By dumping the script args ( $1 == interface, $2 == status ), I determined that the script was being called with 'interface=none' and 'status=hostname'.

I compared NM 0.9.10x to the 1.2.2, and turns out there's a difference in how the hostname is set. In 0.9.10x, setting the hostname is handled by one of the settings plugins. On an Ubuntu system this is either ifupdown or the keyfile settings plugins, neither of which trigger the dispatcher scripts.

In NM 1.2.2, setting the hostname is no longer handled by the settings plugins, and is now instead handled by the core NMPolicy class. The static function settings_set_hostname_cb additionally triggers a call to nm_dispatcher_call with action=hostname.

This fix is to modify 02default_route_workaround to prevent the route flush from occurring if 'status=hostname'.