I'm not sure what you mean by "the routing code is a red herring"?
Also, I'd like to get the exact scenario nailed down. Oliver's description said that he had Wi-Fi enabled the whole time. If so, was the routing table *ever* correct, or was it broken from boot onwards? So which of the following two scenarios do we think is happening? After the initial device boot, it has a valid default route pointing at wlan and network access is enabled, then at some point rild comes along and blindly adds a new default route due to the data call dropping and being re-established. OR At boot, since WiFi is enabled, both the mobile context and the WiFi connection are started by NM, but the rild activation takes longer than WiFi, so rild winning the race and adds it's additional default route. As for the options listed above... 1. I could find no way to do this... 2. I'm not sure what you mean by "trash the 'boot' routing table..."? What what would trigger this script? Would this work for both scenarios mentioned above ( ie. race at initial boot, or mobile link dropping and connection being re-established )? 3. So the basic idea is that you'd add a routing table listener to the NM ofono code, and that this listener would delete a default route added for mobile data if a default route already existed? Isn't there an inherent race ( albeit a small one ) in this approach? I guess one final question is there anyway to configure our system routing policy to prevent this from being possible ( ie. prevent two default routes from being configured )? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1307981 Title: [touch] randomly messed up routing with recent trusty images To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1307981/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
