So confirmed that adding a case for NM_DEVICE_STATE_REASON_MODEM_NO_CARRIER in device_state_changed ( nm- device-modem.c ), causes the connection to be blocked from auto- connecting.
I still see the initial retries decrement log message in device_state_changed ( nm-policy.c ), I mentioned this is due to the transition of the device from 'Activated' to 'Failed', it's not a new activation attempt. When this is logged( w/retries=4 ), I don't see any subsequent attempts to retry, ever. nm-policy controls the clearing of the connection's 'autoconnect_blocked_reason' ( which is what gets used in this scenario to block autoconnect ), and at the moment, nothing done by the NM ofono code is triggering the right state changes to clear the reason when 'Attached' becomes TRUE again. Nor is there a timer set, as is done when an autoconnect sequence exceeds it's retry count ( ie. the ~5m timer mentioned above ). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1418077 Title: After radio technology is changed, mobile-data takes ~5m to re-connect To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1418077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
