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.
It's pointless to have libmm-common around, just merge it into libmm-glib and
make ModemManager depend on libmm-glib directly. At the end, the non-common
stuff in libmm-glib is really minimal.
Some Icera-based modems (e.g. Samsung/Icera Y3300/Y3400) may take a loong time
to run the power down command (see commit 5f1a1cf8). So, for these modems we
will fully skip the power down command run during initialization.
Instead of letting the plugins specify a default storage to use, just look at
the supported ones and use the best one.
"MT is preferred over "ME" or "SM", as "MT=ME+SM"
There is no point in specifying a default 'mem1' memory storage, which is used
for reading/listing/deleting, as those are operations that need a specific
'mem1' set each time.
Also, there is no point in specifying separate default 'mem2' and 'mem3' memory
storages, specially because now we allow Sms.Store() to specify a storage.
So, we will now only have a 'default' memory storage, which is applicable for
both 'mem2' and 'mem3' (storing, sending from storage and deleting).
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
Some of the IP address items will be 0.0.0.0 depending on what the
other items are, like when the duplicate gateway is set on newer
devices, the first gateway address may be 0.0.0.0. Since that's
not a valid IP address, just don't set that member of the config.
Second, the intent with the duplicate gateway is only to use that
when the first gateway was not given (ie, was 0.0.0.0) so fix the
check for that.
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.
This is the port to git master of the following commit:
commit c8153b1ecdec1995258b114c90b575af1e721d3d
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Aug 28 12:16:26 2012 -0500
icera: handle additional IPv4 configuration options
Newer devices like the ZTE/Vodafone K3805-z have an enhanced
%IPDPADDR command that includes a netmask and gateway, and
these are necessary to configure the device since it uses /24
instead of a /32. Since the device is nice enough to tell
us that, we should probably use that information.
Unfortunately the MM API doens't expose the netmask and gateway
yet, so we'll have to add a GetIP4ConfigEx() method or something
like that, but this commit sets us up to do that.
This is the port to git master of the following commit:
commit d2654a287c309346cc46b535dd974b0a5fc06fd4
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Aug 28 12:15:30 2012 -0500
zte: handle Icera-based devics that use DHCP
Since we can't autodetect that the devices use DHCP, we'll need to
tag them with udev rules for the time being.
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 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.
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.
