This patch removes an unnecessary check of unsigned expression >= 0,
which also fixes the following clang warnings:
sierra/mm-broadband-modem-sierra.c:570:18: error: comparison of
unsigned expression >= 0 is always true
[-Werror,-Wtautological-compare]
mode >= 0 &&
~~~~ ^ ~
Bug reported on https://code.google.com/p/chromium/issues/detail?id=235989
Patched by Yunlian Jiang <yunlian@chromium.org>
The GetNetworkTime() response is defined to be an ISO8601 string, which
is in turn defined to be in local time. Make sure that's reflected in
the documentation, and append the timezone offset to UTC where we have
it.
Oddly, Icera devices return their time info in UTC with an offset to
the local timezone, so we have to jump through some hoops there to
convert the response to localtime based on the reported offset.
Some additional fixes by Aleksander Morgado <aleksander@lanedo.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=697372
The USB305 (Icera-based) apparently has a port that replies to everything
with ERROR, and that port is unusable. Make sure it's ignored, otherwise
MM may claim it as the primary AT port since it technically speaks AT.
When the serial port buffer gets full of non-AT garbage during port probing,
we were re-scheduling the next probing step, which is completely wrong, as we
then would be processing the same probing task twice. If we get a buffer full,
just cancel the AT probing cancellable, which would cancel not only the possible
AT probings, but also the custom init if there is any.
Also, make sure that the custom_init() of the plugins out there don't return an
error if the GCancellable is cancelled. Cancelling the GCancellable means we
should just stop the custom_init(), and actually sending an error in
custom_init() means that the port should be set as unsupported by the plugin, so
completely different things.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=696695
Plugins which may support QMI ports need to explicitly request QMI probing
in cdc-wdm devices. This should also avoid probing cdc-wdm ports when we know
that the plugin doesn't support them (e.g. with Ericsson MBM devices).
https://bugzilla.gnome.org/show_bug.cgi?id=696701
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.
Ben Chan
Dan Williams
Aleksander Morgado
Gerald Richter
Marius B. Kotsbak