Some modems return the +COPS operator name in hex-encoded current
character set (as set with +CSCS). Others return the operator name
in ASCII when set to UCS2, while yet others return the ASCII name
with trash at the end (*cough* Huawei *cough*). Handle that better
by not crashing.
Current capabilities is the set of *active* radios that can be used
right now. Modem capabilities are the set of all radios the modem
could use, if some action were performed to enable them if they are
not enabled already (firmware reload, changing allowed mode, etc).
For QMI devices, the DMS Get Capabilities command represents all
radios, and thus "modem capabilities".
But to read *current* capabilities, ie active radios, we need to
query the NAS System Selection Preference and grab the "mode
preference" TLV. Unfortunately that is only available with NAS
>= 1.1, which means older Gobi devices (1K and 2K) don't support
it. So for older devices, we try to get the Technology Preference
(which takes into account user-requested limitations) and then
mask that with the DMS Get Capabilities result for a best-effort
current capabilities.
For example, the Pantech UML290VW reports DMS Get Capabilities
of "cdma, evdo, gsm, umts, lte", but a more limited SSP mode
preference according to what modes are actually enabled. Gobi
1K devices don't support SSP, and the DMS Get Capabilities
reports cdma/evdo or gsm/umts depending on the currently loaded
firmware. Previous to this patch, ModemManager reported all
modes as available on the UML290, ignoring what modes were
actually enabled.
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.
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.
Not all devices present a network interface, and on these devices
we need to fall back to PPP using the standard setup commands. But
they appear to support the Icera custom commands for access technology
and such, so still use those.
Hopefully fixes ZTE MF665C.
If the command we're sending doesn't have a callback, don't try
to call NULL. Triggered if the port got closed (because the modem
crashed, or refcounting errors or whatever) with some code like this:
mm_at_serial_port_queue_command (MM_AT_SERIAL_PORT (port), "+CREG=0", 3, NULL, NULL);
My LG Rumor2 phone (ttyACM0 - AT, ttyUSB0 - QCDM) was never getting
exported after the QCDM port finished probing. Not entirely sure
why, but we should check whether we need to export a modem or not
any time a port gets grabbed.
Need to suggest that it's QCDM since the MMPortProbe stuff
doesn't get passed through to mm_base_modem_grab_port() so
we can't detect QCDM ports automatically there.
Where we have multiple commands that are all supposed to return
the same thing (ie, GMM/CGMM, CSQ/CSQ?) but some modems
support one and not the other, don't exit the sequence early if
the modem doesn't support one of them.
Gobi modems with CDMA firmware don't support the Cxxx variants
so the returned ERROR (CME error 100) made the generic parser
break out of the AT sequence without trying the additional
commands that are supported.
Make port roles more flexible. We have modems that do PPP
on interfaces other than the primary interface, and that
wasn't possible with the old code. So clean up all that
logic and move the port organization code into the core
so we can reduce code in the plugins.
In the new world order, the plugins say whether the port
is a QCDM port, an AT port, or ignored. If it's an AT
port the plugins get to tag it as primary, secondary, or
PPP, or any combination of the 3. This allows for modems
where PPP should really be done on the secondary port
(Huawei E220, Sierra devices) so that the primary port
stays open for command and status.
Modem subclasses no longer get asked to handle port grabbing
themselves. Instead, that's now done by the generic classes
(MMGenericCdma and MMGenericGsm) and the plugins are notified
when a port is grabbed so they can add unsolicited response
handlers for it. After all ports are grabbed by the generic
classes, they get "organized", which assigns various ports
to the roles of PRIMARY, SECONDARY, DATA, and QCDM based
on specific rules and hints that the plugin provided (which
are expressed as MMAtPortFlags). The plugins then have
a chance to perform fixups on the primary port if they choose.
The plugin code is responsible for determining the port
hints (ie MMAtPortFlags) at probe time, instead of having
a combination of the plugin and the modem class do the
job. This simplifies things greatly for the plugins at
the expense of more complicated logic in the core.
This likely has no effect, but just make sure the regex stops
grabbing message content when it hits the CF/LF that terminates
the message content in text mode.
It seems that even though the firmware says it supports
specific CNMI notification values, it really doesn't. Also
set storage to the SIM until we support automatically
determining the right storage in MM. XU870 does not
support ME storage according to +CPMS=?.
Comparing dumps from UML190 in different modes, UML290, and PC5740
revealed what the 'service' bit was, which matches up nicely with
the SERVICE_* strings in the Windows connection manager DLLs if
you interpret them in reverse numerical order.
For the global mode stuff, looking at USB wire captures shows that
C8 03 and C8 04 get used right before the NETWORK_INFO (C8 0B)
shows access technology changes, which means they are probably the
commands that switch global mode around.
Dan Williams