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.
WMC ports will return "ERROR" to all AT commands, except for "AT" itself. So
just provide a custom AT probing logic, which uses "ATE0" instead, and assumes
the port is not an AT port if an error is returned.
Since glib 2.32, we can use g_byte_array_new_take() to build a new GByteArray
from an own allocated buffer, so skip playing with the GByteArray internals.
We don't support absolute or enhanced format for validity, but we still need to
properly skip those fields if given.
According to GSM 03.40, they are both always 7 bytes, not just 1.
Pantech UMW190 modem uses a custom +CMGL response which includes only
three fields before the actual PDU, e.g:
+CMGL: <index>,<status>,<something>\r\n<PDU>
instead of what we had before:
+CMGL: <index>,<status>,<alpha>,<length>\r\n<PDU>
The CMGL parsing logic is now updated to use a regex to match the reply, and
also considering the UMW190 specific case.
Actually, we end up reading only the two first fields (index and status) which
are the ones we really need, so we skip the <length> and the <alpha> if given.
Added also unit tests to cover all these known cases.
Partially fixes https://bugzilla.gnome.org/show_bug.cgi?id=696723 (missing the
actual PDU parsing fixes).
NM attempts to set allowed and preferred mode during the connection
process. The plugin x220x does not handle properly when NM request
allowed mode to '2g, 3g' and the preferred mode to 'none'.
This commit attempts to solve the problem described above. When this
situation happens, establish the mode of the modem has 'ANY' (which
seems the safest one) instead of just throwing an error.
Signed-off-by: David Castellanos <dcastellanos@indra.es>
MBM modems will lie about the unlock status just after having sent a
correct PIN or PUK. So, explicitly wait to get in READY state after having
sent the PIN or PUK, before keeping on.
https://bugzilla.gnome.org/show_bug.cgi?id=696702
