Comment 16 for bug 1418077

So what seems to be happening, is that the radio technology switch causes the modem to unregister from the current carrier, and attempt to re-register using the new tech preference ( eg. umts, lte, gsm, ... ). This will cause the ofono ConnectionManager 'Attached' property to return FALSE until the phone re-registers and re-attaches to GPRS.

NM detects the device change state from 'Activated' to 'Failed' ( more on this later ) and in turn schedules an auto-activation attempt of the connection ( context1 ). As the modem's not attached, the activation fails and the retry_count gets decremented, and it tries again repeatedly ( with no delay ), until the retry_count ( initialized to four ) drops to zero.

At this point, NM disables the connection and adds a timeout of 300s in the future which will call a policy function that resets the connection's retry_count, and triggers a new autoconnect sequence. 300s / 60s/m == 5m, our mysterious delay.

What we need is some mechanism for autoconnect to be blocked when the modem is not registered. It looks like nm-device-modem.c implements something like this in it's device_state_changed(). It checks a bunch of reason codes, but NM_DEVICE_STATE_REASON_MODEM_NO_CARRIER ( which is the error returned by stage1 if the modem isn't registered ) isn't checked.

The code also would need a mechanism which would re-enable the autoconnect when the device becomes enabled again ( ie. when 'Attached' becomes TRUE again ).

Also with regards to the device 'Activated' to 'Failed' transition, it's a bit odd that 'Disconnected' isn't used, as 'Failed' causes a retry attempt to be wasted ( see nm-policy.c ) because device_state_changed() treats a new state of FAILED as a connect failure and decrements the retry_count.