Newer firmware for Huawei devices will not split the IPv4 and IPv6 info in
different lines for the ^NDISSTATQRY reply; instead they will be included in the
same line. E.g. instead of
^NDISSTATQRY: 1,,,IPV4
^NDISSTATQRY: 0,33,,IPV6
OK
We may have:
^NDISSTATQRY:0,,,"IPV4",0,33,,"IPV6"
Also note the optional spaces after the ':', and that in the new version the
strings are enclosed in double quotes.
https://bugzilla.gnome.org/show_bug.cgi?id=705339
Introspection can't copy with a '.' in the value nicks, so just remove those.
Note: This could be considered an ABI break!
Bug #705641.
Patch based on a previous one from Christian Persch <chpe@gnome.org>.
Along with a new '--cdma-activate-manual-with-prl'.
These can be used to request CDMA Manual Activation, like:
$> sudo mmcli \
-m 0 \
--cdma-activate-manual="spc=123456,sid=ab,mdn=0123456789abcde,min=0123456789abcde"
Or:
$> sudo mmcli \
-m 0 \
--cdma-activate-manual="spc=123456,sid=ab,mdn=0123456789abcde,min=0123456789abcde" \
--cdma-activate-manual-with-prl=/path/to/my/prl.data
The format of CREG/CGREG/CEREG responses is not very precisely defined
in or strictly enforced by the 3GPP specifications. That leads to the
fact that some modems put leading zeros in integer type fields (e.g.
<n>, <stat>, <AcT>), and not all modems put double quotes around string
type fields (e.g. <lac>, <ci>) in those C*REG responses.
For example, 0001 can be a valid value for both <stat> and <lac>. The
original C*REG parsing code in ModemManager could potentially interpret
'+CREG: <stat>,<lac>,<ci>,<AcT>' as '+CREG: <n>,<stat>,<lac>,<ci>'. This
patch addresses this issue by refining the regular expressions returned
by mm_3gpp_creg_regex_get() with the following assumptions:
1. If a modem puts leading zeros in integer type fields, it puts double
quotes around string type fields.
2. If a modem omits double quotes around string type fields, it does not
put leading zeros in integer type fields.
This patch modifies the regular expressions for parsing ^RSSI, ^RSSILVL,
and ^HRSSILVL responses to handle any whitespace that is inserted
between the colon and the RSSI value.
The issue is identified by Dan Williams <dcbw@redhat.com>
When we're exposing not-yet-completed multipart messages, we need to provide a
correct value for the validity property, or gdbus may crash, see e.g.:
https://bugzilla.gnome.org/show_bug.cgi?id=704319
With a non-zero send delay, the communication over the ttyACM port of
the modem is not very stable when USB auto-suspend is enabled for the
modem. The send delay is not necessary and thus removed by this patch.
Ori Inbar <ori.inbar@altair-semi.com> reported the issue and suggested
this fix.
