That routing code is a red herring, it's actually never reached in the case where wifi is already activated, because wifi remains the best IP4 connection available (given that it has a higher priority than modems).
>From what I see here, it seems like rild is just *always* setting the route, and this is basically just a race between NM and rild: if rild happens to write the route before NM has activated the primary; then you'll get a valid routing table (because the rild route gets replaced by NM's route via wifi), but if it happens after, NM rightfully no longer cares about what happens to the routing. This *is* proper behavior since we can't go trash routes that could be added after the connection by a sysadmin or some other process... I'd very much like to understand why this suddently became an issue -- I don't think either code bases changed much in relation to routing, so something ought to have changed in the environment on mako. I see two options, listed in order of preference (not necessarily feasibility): 1) Convince rild to never set up the default route. I would have hope this to be doable via an android property that can be set, I tried to find a property that looked related, but without results yet. It could well not be feasible at all, sadly. 2) Ship a custom dispatcher script in lxc-android-config; to, on purpose, trash the "boot" routing table which rild abuses to do this. I would rather do this as a dispatcher script we ship only on touch, because I think it's explicitly Very Very Wrong to muck with the routing table arbitrarily for other images. I did already test this as a workaround with the expected successful result, see http://paste.ubuntu.com/7376744/. 3) Find a way to catch the precise, exact route using netlink in the ofono modem plugin of NM; and explicitly RTM_DELROUTE it. This is the safest to ship everywhere, but requires the most effort. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1307981 Title: [touch] randomly messed up routing with recent trusty images Status in “network-manager” package in Ubuntu: Confirmed Bug description: I have no clue when exactly it started (probably before image 290), but since a while i experience random issues where the browser suddenly doesnt find websites anymore ... digging deeper i can see that the routing table is completely messed up having two default routes: root@ubuntu-phablet:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 37.85.159.174 0.0.0.0 UG 0 0 0 rmnet_usb1 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 wlan0 37.85.159.172 0.0.0.0 255.255.255.252 U 0 0 0 rmnet_usb1 192.168.2.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan0 i did not roam or switch networks, this phone was constantly on wlan in the same room. afer a reboot the routing is normal: root@ubuntu-phablet:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 wlan0 37.84.75.140 0.0.0.0 255.255.255.252 U 13 0 0 rmnet_usb0 192.168.2.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1307981/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
