Split into two different actions the actual COPS? response parsing and the
operator name normalization process.
Also, allow parsing not only the operator string, but also the format, mode
and the optional access technology value.
* Add new async virtual method init_current_storages to
MMIfaceModemMessaging
* Add logic of init_current_storages to MMBroadbandModem
* Add step "INIT_CURRENT_STORAGES" in MMIfaceModemMessaging
initialization in order to load and store current SMS
storages for mem1 and mem2.
* Add usage of current sms storage value for mem1 in place
of an empty string parameter when the command AT+CPMS
is used.
https://bugs.freedesktop.org/show_bug.cgi?id=93135
The CPMS test parser was expecting 3 groups (parenthesis enclosed lists) of
memory IDs, e.g.:
+CPMS: ("SM","ME"),("SM","ME"),("SM","ME")
But some modems like the Huawei MU609 may just report single elements, not
groups, e.g.:
+CPMS: "SM","SM","SM"
This patch avoids using g_strsplit() to split the groups, as that is unaware
of the possible replies without groups. Instead, a new helper method is
implemented which does the group/item split itself, considering also the
possibility of a reply with mixed groups and non-groups, like e.g.:
+CPMS: ("SM","ME"),"SM","SM"
Additionally, we also now support the case where the groups are empty, e.g.:
+CPMS: (),(),()
https://bugs.freedesktop.org/show_bug.cgi?id=92243
Variability in the response style from certain modems causes the parsing
of the +CGMR response to fail. For example, the Telit HE910 inserts an
empty string ("") in the second field of the response, causing the
sscanf implementation to fail.
This patch converts the parsing of the CGMR response to a regex that
allows for more flexibility and robustness, and adds unit tests around
the parsing call.
Signed-off-by: Nick Stevens <Nick.Stevens@digi.com>
This patch modifies mm_3gpp_parse_iccid() to auto-detect if an ICCID
response is character swapped or not by comparsing the major industry
identifier part of the ICCID response to the known value (89) for
telecommunication purposes. This addresses the issue where the same AT
command (e.g. AT^ICCID used by the huawei plugin) does not report ICCID
in a consistent format.
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.
Tests had either their own g_print()s or they would enable a _mm_log() method to
get all g_debug()s from the libraries printed. In order to cleanup the result of
the tests run, avoid this stdout dumps by default, and only enable them if
explicitly enabled in CFLAGS, e.g.:
$> ./configure CFLAGS="-DENABLE_TEST_MESSAGE_TRACES"
And also make it a list of masks, specifying which are the specific combinations
supported, not just one mask with all.
E.g.:
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7710'
| revision: 'SWI9200X_03.05.19.04ap r5475 carmd-en-10527 2012/09/17 17:57:14'
| supported: 'gsm-umts
| gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '358178040668164'
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).
+GSN response differs widely between modems. Some prefix the
MEID and/or ESN with 0x, some have leading zeros, some return the
MEID and the ESN, and some append the serial number to the end of
the IMEI. Handle that and make the ESN, MEID, IMEI, and
EquipmentIdentifier parsing consistent.
This patch adds the support for solicited/unsolicited EPS network
registration status via AT+CEREG, which is configurable via the
'iface-modem-3gpp-eps-network-supported' property of the
MMIfaceModem3gpp interface and is disabled by default.
Instead of using a predefined set of string values for 'ip-type' in
Modem.CreateBearer() and Simple.Connect(), we'll use an enumeration. The
implementation will then need to convert the requested IP family type to e.g.
the correct PDP type in 3GPP modems.
This change also consolidates the use of enums in dictionary properties when
possible to do so, as with the Rm Protocol.
We provide the result of the +COPS=? parsing in a GList of MM3gppNetworkInfo
structures. We avoid the previous hash table, or using a dictionary, as a
list of structs with a predefined set of elements, which should be easier for
plugins wanting to make their own version
