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
Pass the device's hardware IDs through modem creation and use them
when calculating the device's identifier. Add a bunch of testcases
for real hardware to ensure we don't break the device ID in the
future unless we really want to.
When a modem sends both CREG and CGREG in the same response packet,
the parser was failing to correctly distinguish which response
was being parsed, since the string passed to g_regex_match() is
the whole response including both CREG + CGREG.
Aleksander Morgado
Dan Williams
Ben Chan
Michał Sroczyński
Vincent Untz