For loading current capabilities we use a mix of "Technology Preference" (TP),
"System Selection Preference" (SSP) and DMS-reported capabilities. But, as we
also use TP and SSP for allowed modes, it may be the case that we end up
leaving 4G out of the allowed modes, which afterwards will make the modem not
report LTE as current capabilitiy, as TP/SSP don't include LTE.
So, just assume LTE is a current capability if DMS-reported capabilities include
it. We can really do this because LTE is the only 4G technology, the same logic
wouldn't apply correctly for 2G or 3G (due to having different techs for 3GPP
and 3GPP2).
Sometimes invalid signal strengths will be returned by the modem,
which we should ignore. Otherwise they make the reported signal
quality bounce around from eg 21% -> 100%, or cause access
technology updates for radio interfaces that can't possible have
a usable signal.
We don't want to support only 'relative' validity, so don't assume that the
Validity property will always be a uint32 value.
Instead, we define the Validity propery as '(uv)' tuple, where the first value
(a MMSmsValidityType) specifies the type of validity, and the second value is
a variant formatted accordingly to what the validity type specifies (e.g. a
uint32 value if the type is MM_SMS_VALIDITY_TYPE_RELATIVE).
We remove "/SRC/AMSS" as a hint of non-AT port, as it really comes in ATI
replies, see:
[mm-at-serial-port.c:408] debug_log(): (ttyUSB6): <-- '<CR><LF>Manufacturer: Sierra Wireless, Incorporated<CR><LF>Model: USB 306<CR><LF>Revision: M3_0_10_1AP C:/WS/FW/M3_0_10_1AP/MDM8200/SRC/AMSS 2010/03/29 17:52:11<CR><LF>IMEI: xxxxxxxx<CR><LF>IMEI SV: 11<CR><LF>FSN: xxxxxxxxxx<CR><LF>3GPP Release 7<CR><LF>+GCAP: +CGSM,+DS,+ES<CR><LF><CR><LF><CR><LF>OK<CR><LF>'
[mm-serial-parsers.c:188] mm_serial_parser_v1_parse(): Got response filtered in serial port: Not an AT response
[mm-port-probe.c:148] mm_port_probe_set_result_at(): (tty/ttyUSB6) port is not AT-capable
Remove the additional check for AT responses done *after* having parsed the
response. This check only worked whenever the response string ended up matching
one of the regular expressions in the parser, which of course wasn't always.
We will check each string with our custom filter before even trying to
parse them. A MM_SERIAL_ERROR_PARSE_FAILED error will be issued whenever the
string doesn't match the filter.
The serial parser will now allow specifying a custom user-provided filter, which
is applied before even trying to match successful/error responses. This filter
provides a very early barrier to detect strings that are clearly not going to
match.
E.g. this filter may be used during port probing to early detect non-AT ports.
Also report as non-AT responses if the NUL bytes are embedded within a stream
of bytes which doesn't start with NUL. This e.g. applies to CnS ports from
Sierra modems, which show streams like:
~\0\245y\0}^T1_0_4_0BT R372 CNSZXD00000061 2011/05/12 15:25:25\0\0\0\0\0\0\0\0\0
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0T1_0_4_0AP R372 CNSZXD00000061 2011/05
/12 15:25:25\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
03\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0~~
\0Tb\0T1_0_4_0AP R372 CNSZXD
When there is an error in the connection attempt we need to close the dialling
port ourselves. In the case where we got an error and we also got cancelled,
we need to make sure that the port gets closed.
MM doesn't yet parse the +CNMI=? response and dynamically figure out
what indication settings are supported, so add another last-resort
CNMI setting for the UMW190 which doesn't support any <ds> at all.
And the commands shouldn't be cached, so fix that too.
