This is the port to git master of the following commit:
commit fb3187847b9c62d5205962c3c707ac1f44eaddcc
Author: Eric Shienbrood <ers@chromium.org>
Date: Thu Aug 11 16:58:34 2011 -0400
icera: retry configuring PDP context if it fails.
If a connect operation is attempted immediately after a disconnect,
it sometimes fails with CME error 583 - "a profile (CID) is currently
active". Apparently, even though the preceding operation (%IPDPACT)
to deactivate the PDP context returned an OK response, the context
is not really completely available until a fraction of a second
later. This causes the %IPDPCFG operation that is part of the
subsequent connect attempt to fail with error 583. This change
retries the %IPDPCFG after a one second delay.
BUG=chrome-os-partner:4936
TEST=This can be tested from the UI, but I found it easier to produce
the timing needed to trigger the bug by running mm-disconnect and
mm-connect from a shell.
Start out with the modem in the connected state. In the shell, run
sudo /usr/local/lib/flimflam/test/mm-disconnect; sudo /usr/local/lib/flimflam/test/mm-connect --number='*99#' --apn=wap.cingular
modem-manager should emit the log line "Invalid error code: 583".
Prior to this change, the connect operation would fail. Now it should
succeed.
Change-Id: I6ae0e6a9f5405b54b0b465fe91d9542529f365c2
Reviewed-on: http://gerrit.chromium.org/gerrit/5781
Tested-by: Eric Shienbrood <ers@chromium.org>
Reviewed-by: Nathan J. Williams <njw@chromium.org>
Different ports of the same modem may get handled by different drivers. We
therefore need to provide a list of drivers (new `Modem.Drivers' property with
signature 'as') instead of just one (removed `Modem.Driver' property with
signature 's').
$ sudo mmcli -m 0 | grep drivers
| drivers: 'qcserial, qmi_wwan'
This patch modifies MMBroadbandModemIcera as follows:
- Change modem_load_current_bands to report only bands that are
currently enabled
- Change modem_set_bands to handle setting ANY band in a way that no
forbidden bands are activated.
Turns out we can check supported bands by asking the modem what
the enabled state is for the bands it says it supports, and then
setting the enabled state to what it currently is. For bands the
modem actually doesn't support, it'll return an error. Use that
to build up the modem's actual supported band list.
In the connection and disconnection sequences, we make sure that the Bearer
object is valid by keeping a reference in the Dial3gppContext and
Disconnect3gppContext (actually, another one kept by the GSimpleAsyncResult as
well). But we are considering here the case where the context is completed and
freed by an unsolicited message handler before we get the reply to the AT
command, so to properly ensure that the bearer object is still valid when we try
to check if the context is in the priv struct, we need to keep an extra ref
around.
In both the connection and disconnection sequences, we keep the context in the
private info of the Bearer object, so that we can complete and free it when we
receive %IPDPACT unsolicited messages. Now, the reply of the %IPDPACT itself may
get processed as an unsolicited message, so effectively we're processing and
finishing the connection/disconnection context *before* we process the reply of
the AT command.
This patch ensures that we do not try to re-use the connection/disconnection
context after it has been processed by the unsolicited messages handler.
Aleksander Morgado
Ben Chan
Dan Williams