GNOME Bugzilla – Bug 685578
Samsung Icera modem goes into a weird state it cancels a connection in progress
Last modified: 2012-10-30 19:40:18 UTC
Created attachment 225898 [details] ModemManager log This issue is specific to the Samsung Icera plugin. The attached ModemManager log demonstrates the issue. When a connection attempt is cancelled, MMBroadbandBearerIcera issues a 'AT%IPDPACT=<cid>,0' command to deactivate the PDP context for the connection. However, calling 'AT%IPDPACT=<cid>,0' while the PDP context is still activating (i.e. after calling 'AT%IPDPACT=<cid>,1' and before receiving a '%IPDPACT=<cid>, 3, 0' unsolicited response) seems to bring the modem into a weird state: - The 'AT%IPDPACT=<cid>,0' command fails with a CME ERROR: 767 (operation failed). Retrying this command a few times with a 1-second delay doesn't seem to help. - Subsequent 'AT+CGDONT=<cid>,"IP",<apn>' command fails with a CME ERROR: 583 (CID is currently in use). - The PDP context activation isn't really deactivated or cancelled, as indicated at the end of the log, the modem issues a '%IPDPACT=<cid>, 3, 0' unsolicited response.
Dan, Could you try to reproduce this issue in a non-Samsung Icera-based modem? Maybe forcing the disconnection (e.g. with a hardcoded cancel of the cancellable) as soon as we send the 'AT%IPDPACT=<cid>,1'.
Currently we handle two cases where we send the AT%IPDPACT=<cid>,0 as part of the 'reset' attempt to cancel the connection request: when cancelling and if attempt times out. For what I can see, if that command can't be used to cancel the connection attempt (only to cancel the already established connection) then we're definitely stuck in the case where we really do need to wait for the connection attempt to finish before we can cancel it. One thing is for sure: we won't be able to try to re-connect until the first connection attempt is finished, so I think we should focus on trying to handle that. So, a first approach would be to avoid the connect_reset() call that we do on connect_timed_out_cb() and connect_cancelled_cb(). If we do this, ModemManager will afterwards think that we're disconnected, even if the modem is still going on with the connection attempt. The key thing here is that during this time we shouldn't allow any new connection attempt (e.g. we return a WRONG_STATE error) *and* we should also still wait for the real unsolicited reply to the previous connection attempt, so that we disconnect it as soon as the modem tells us it's connected. This approach actually leaves the command timeout pretty useless, unless we use it for this new logic. I'll try to see if I can hack something like this.
Created attachment 227048 [details] [review] Patch for the issue Ben, can you install the attached patch and try to reproduce the issue? Please give me debug logs once you reproduce it. Dan, any comments on the patch?
I've been testing the patch with an Option/HSO modem, which also shows this issue, and seems to work well enough. Already pushed the fix, please reopen if you still find the issue. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.