This is a port to git master of the following commit:
commit 0b051f9c7033143c56f59267794d1cadf4bd3416
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Aug 27 10:24:50 2012 -0500
gsm: better handling of IMSI response
Moto EZX devices prefix the response with "+CIMI:" while most
devices do not.
This is a port to git master of the following commit:
commit c21e29c50b5661308fb3b223c05f6942c06dc15d
Author: Dan Williams <dcbw@redhat.com>
Date: Fri Aug 24 13:31:04 2012 -0500
novatel: fix checking ERI for roaming/home decision
More fallout from b22b2d99db
which changed the return type of the qcdm_result_get_*() functions.
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>
This is the port to git master of the following commit:
commit e0242b4db7fb1556e79f6829d22edf411f9f6ba4
Author: Dan Williams <dcbw@redhat.com>
Date: Thu Aug 23 21:14:38 2012 -0500
sierra: fix detection of APP1 port
The APP1 port (which has a limited AT parser) doesn't prefix
its replies with <CR><LF> like nice modems do, and that means
it runs afoul of the echo removal bits of the AT serial port
code. We need to parse the whole string even though it's not
prefixed properly to find the APP1 string in the response.
This is the port to git master of the following patch:
commit 21e66dfa1774ac2ee037ac8b6e8bb4d71a6f7931
Author: Dan Williams <dcbw@redhat.com>
Date: Thu Aug 23 21:13:35 2012 -0500
core: add function to open probe ports without removing echo
Some devices (Sierra GSM ones) return stuff we need but don't
bother to prefix it with <CR><LF>, so we need to optionally turn
off the echo removal at probe time.
Don't abort the connection if the modem reports unregistered in either
3GPP or CDMA, as mixed CDMA+3GPP modems may connect even if not registered
in both technologies.
Some sierra modems (e.g. MC7710) have a secondary port that likes to reply OK
to any AT command passed. Detect that as soon as possible, and don't consider
the Icera port probing result from that secondary port.
QMI and wwan ports come in pairs. Each wwan port has an associated control QMI
port, which is the only port allowed to send the Start|Stop Network QMI requests
to start|stop the connection in the given wwan interface.
Paired QMI and wwan interfaces (should) share the same parent udev device,
quoting Bjørn:
"If we ignore the unfortunate 3.4 and 3.5 kernels, then a matching wwanX
and cdc-wdmY set will always share the same parent USB interface on QMI
devices.
Having the same parent USB device is *not* sufficient. You cannot control
wwan0 using cdc-wdm1 in the above example."
When bands or allowed modes are changed, the modem will very likely reset its
current registration and start from scratch. We will now give it some seconds
to settle down before going on with the connection request, so that the modem
has enough time to report being unregistered. Without this sleep time, the
unsolicited message reporting being unregistered may arrive *after* having
checked registration status in the Simple connect sequence, and therefore we
end up failing the connection request.
Whenever we query current unlock required status and we get that we're unlocked,
we'll launch the after-sim-unlock step so that we try to ensure that the SIM is
ready.
We'll try to cope with getting devices being reported in either 'usb' or
'usbmisc', trying to avoid the need of checking kernel version during runtime.
