@Alfonso So looking closer at NM 0.9.8, the routing is updated by nm-policy.c in its device_state_changed() function. It calls update_routing_and_dns() in several places, which in turn calls update_ip4_routing(), which in turn calls nm_system_replace_default_ip4_route(). Only the last function returns an error code, so if adding the default route fails, the error doesn't bubble up, and the system is left partially configured.
I hacked nm_system_replace_default_ip4_route() to return an error on it's third invocation, then rebooted the system with WiFi disabled. The first call to replace_default_ip4_route() happens when the mobile data connection is established on reboot. Next I activated WiFi and the phone connected to an AP, that's the second route call. Finally I disabled WiFi and this triggers the third route call which fails. At this point we have a connection that NM still thinks is connected, with an empty routing table. Next I deactivated the context manually, and NM turned around and re- established the connection, so I *think* this proves that the scenario you described in comment #26 isn't happening with NM 0.9.8. At this point, as changing the NM logic isn't super straight-forward, I would suggest that we don't attempt to patch NM for utopic-RTM at this point, unless someone else is able to prove for certain that NM can get wedged in a bad state when the routing configuration fails. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1435328 Title: Leaving Wifi does not connect to mobile carrier data (GSM) To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1435328/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
