Older devices may crash if asked to connect right after sending the
PIN and unlocking the SIM; they simply stop responding to AT commands
around the first request for access technology and then reboot. A
delay seems prevents this behavior.
Since it's not uncommon to require a delay after SIM unlock, add one
for newer sierra_net devices as well, even though we're not quite
sure if they need one or not. It doesn't hurt, at least.
'result' may be NULL even if no error is set. Errors aren't set
because we want to continue the !TIME/!SYSTIME sequence regardless
of errors, so we can figure out which command the modem supports.
Trying to get a uint32 out of a NULL GVariant makes glib complain,
and it's wrong, so don't do that.
Instead of deciding in advance which data port to use, we let the dialling
operation gather it. For the generic dialling logic, ATD-based, always an
'AT' port will be used as data port, even if we grabbed a 'net' port. Those
plugins that can work with 'net' ports will grab the specific 'net' port
themselves.
Sierra CDMA devices don't always have QCDM ports, or if they do,
they aren't always usable. Try Sierra-proprietary commands for
loading the modem's MDN and fall back to QCDM if that fails.
This logic is now implemented by the parent broadband modem object.
Also, implement a custom initial power state loading, so that CDMA-only modems
get marked as 'offline', in order to launch !pcstate=1 to power them up during
the first enabling. The custom initial power state loading will run the parent's
implementation in non-CDMA-only modems.
Specially the first time that CFUN=1,0 is issued after the initial power up, we
really need to wait more than 3s for the AT command reply. Otherwise, the modem
won't like it and it will reset itself :-/
Unfortunately, Sierra secondary APP ports reply to +GCAP with
only "OK", and not their APP port number or model number. So instead
of using +GCAP, we have to use ATI to get secondary port information.
This allows us to detect which port is the APP1 port that we can
potentially use for PPP, leaving the primary port available for
control and status.
Also, some modems have up to 3 or 4 APP secondary ports, which we
need to ensure aren't used as primary. The previous check for +GCAP
handled that, but let's make it more explicit.
AT+GCAP reply:
OK
ATI reply:
Sierra Wireless, Inc.
C885
APP1
OK
See also: 3f3987e09ee762e48c1d53cb42a1288ce9f332cb (MM_06)
Turns out older devices (like the C885/AT&T Mercury) crash often
when we don't wait for them to settle from CFUN=1. 5 seconds is
too short, but the crashes go away when we wait for 10 seconds.
Newer modems like the USB306 don't have this problem, so we just
check to see if the modem is a DirectIP device (using sierra_net)
and only use the shorter timeout for those newer devices.
This is a separate problem from some older modems returning ERROR
to valid commands that are sent too soon after CFUN=1, which was
observed on really old devices like the PCMCIA 860.
All Sierra devices appear to require short delay after powering up,
otherwise subsequent commands may return errors. Older devices need
longer so ensure new devices are penalized just for being new.
This is the port to git master of the following commit, for which we
don't need to do #2:
commit 814febe1fd9baacdb33c79f11c140187df36c4f1
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Oct 30 16:16:25 2012 -0500
sierra: fix CFUN power up delay handling
1) all Sierra devices appear to require short delay after powering up,
otherwise subsequent commands may return errors. Older devices need
longer so ensure new devices are penalized just for being new.
2) When the modem is already in full functionality status and no power
up command was sent, there's no need to delay, which was happening
regardless of what state the modem was already in. Detect whether
the power up was actually executed (response and error will be NULL)
and only delay if it was executed.
Some Sierra modems trigger a reset of the modem when sending +cfun=1.
All sierra modems supports a second parameter to indicate that no
reset is to be done: "+cfun=1,0".
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
For those who don't care about the QMI support through libqmi-glib, or if you're
stuck with glib 2.30 (libqmi-glib requires 2.32), this configure switch allows
disabling the QMI support completely.
The logic to detect cdc-wdm ports is still in place, but the QMI probing is
never launched at them. Also, all QMI-related objects won't be compiled.
AT!SELRAT=?
!SELRAT: Index, Name
00, Automatic
01, UMTS 3G Only
02, GSM 2G Only
03, Automatic
04, Automatic
05, GSM and UMTS Only
06, LTE Only
07, GSM, UMTS, LTE
Most Sierra PPP-based devices are supposed to allow PPP on the
APP1 port, which has a dumb AT parser, leaving the main port
(with the intelligent AT parser) free for status and signal strength.
But out of all the devices I've tested it with (8775, 8781, AC881,
and C885), only the C885 actually works. The rest (including three
different firmware versions for the 8775) either crash or disconnect
shortly after PPP starts.
To help figure out which devices actually support this, when
running MM in debug mode, users can set the MM_SIERRA_APP1_PPP_OK
environment variable and assume the APP1 port allows PPP. This
is only for debugging purposes.
This is the port to git master of the following commit:
commit d1be19d231a395339b1f452d1a30b73ea77ad528
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Aug 28 21:58:43 2012 -0500
sierra: fix CSQ handling on APP1 port
The APP1 port doesn't always prefix its replies with <CR><LF> which
runs afoul of the built-in echo removal. Since Sierra modems are on
the whole well-behaved WRT echo removal, just disable it on the
secondary ports. Only changes behavior for PPP-based devices since
they are the only ones that use the APP1 ports.
This is the port to git master of the following commit:
commit 44f70121f75d59dbf31a4a9a1a4e87293e509e7a
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Aug 28 20:18:40 2012 -0500
sierra: use DHCP for the USB 305 (AT&T Lightning)
For some reason, my AT&T Lightning just doesn't work with static
IP (AT%IPDPADDR) any more. No traffic passes even though everything
is set up the way it was before. No idea what happened. Using
latest firmware 2.0.0.11.
But what's interesting is on Windows the generic Sierra Watcher
app uses DHCP. But on Linux, when using AT%IPDPACT, DHCP doesn't
work. That's odd. But it turns out the modem supports the
"standard" Sierra proprietary AT!SCACT commands, and that
*does* make DHCP work. Crazy no? So since the Windows app
uses DHCP, it's likely that the non-DHCP case (AT%IPDPACT/AT%IPDPADDR)
either isn't well tested or isn't well supported. With that
in mind, let's just use DHCP for this device in Linux too.
Some Sierra modems (e.g. MC7710) will report LTE-specific supported modes in the
AT+WS46=? reply, but not +CLTE capability in the AT+GCAP reply:
AT+GCAP
+GCAP: +CGSM
OK
AT+WS46=?
+WS46: (12,22,25,28,29)
OK
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.
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.
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'
