Age | Commit message (Collapse) | Author |
|
The PDP contexts that are found with an empty APN configured are right
now used as placeholders that can be overwritten with the user
provided APN if no direct match is found.
We want to keep that logic in place, but for the case where we do get
an empty APN requested by the user, we need to perform the full
context match, so that the first PDP context matching the empty APN is
used.
Right now we're overwriting with the empty APN again the last PDP
context found with an empty APN, which doesn't make much sense:
Apr 27 08:15:21 ModemManager[4251]: <debug> Found '3' PDP contexts
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=1] [type='ipv4'] [apn='']
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=2] [type='ipv4'] [apn='broadband']
Apr 27 08:15:21 ModemManager[4251]: <debug> PDP context [cid=15] [type='ipv4'] [apn='']
Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 1 and no APN
Apr 27 08:15:21 ModemManager[4251]: <debug> Found PDP context with CID 15 and no APN
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 3 (open)
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3) device open count is 2 (close)
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): --> 'AT+CGDCONT=15,"IP",""<CR>'
Apr 27 08:15:21 ModemManager[4251]: <debug> (ttyUSB3): <-- '<CR><LF>OK<CR><LF>'
|
|
As a precursor to a generic load_unlock_retries method, move the
CSIM Response parser from the Telit plugin into the core code.
|
|
Also:
* define the leading '+' as a escaped value
* allow any number of spaces between '+CCLK' and the string value.
|
|
|
|
|
|
Telit LTE modems could reply to +WS46=? with:
+WS46: (12,22,25,28-31)
This patch extends +WS46=? response parser to support ranges.
|
|
Don't blindly try '+CMER=3,0,0,1' to enable and '+CMER=0' to disable
Mobile Equipment Event Reporting. We now query the device for the
supported formats and use that info to build commands that will work.
|
|
|
|
Instead of having the parser return separate list of supported flow
controls for TE and TA, we simplify it by only returning those
settings that apply to both TE and TA.
This logic isn't perfect either, though, as some settings (e.g. '3' in
TE in some modems, specifying a different XON/XOFF behavior) may not
have a corresponding setting in the other end.
The most common cases we care about (i.e. standard XON/XOFF, RTS/CTS)
should be properly reported with this logic.
|
|
The operator code (MCCMNC) may also be given encoded in the current
charset (e.g. UCS2).
Based on a patch from Colin Helliwell <colin.helliwell@ln-systems.com>
|
|
The method doing the operator name normalization takes as input the
current configured modem charset. If this is UCS2, we will now just
assume this is a hint: the string may or may not come in hex/UCS2.
This logic makes the custom operator name loading in Huawei unneeded,
if the modem is configured in UCS2, we still properly process operator
names coming in plain ASCII.
|
|
We want a parser that returns the full list of combinations found.
|
|
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
|
|
Added support for 4-digit format years (i.e. YYYY), and also made the
timezone information optional, as per +CSDF in 3GPP TS 27.007.
https://bugs.freedesktop.org/show_bug.cgi?id=95319
|
|
u-blox modems will append a string showing the MCC and MNC info to the access
point name listed in AT+CGDCONT? responses. We will try to detect when that
happens, and we just accept the match.
The logic doesn't just look for a string prefix; it also looks for the special
MCC + MNC suffix, which is much more restrictive, to try to avoid false
positives.
|
|
|
|
|
|
Introduce "sms only" and "CSFB not preferred" home/roaming states to be reported
for the CS context, while already registered on LTE.
Based on 3GPP TS 27.007 v13.5.0.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Cinterion PHS8-US devices send split PDP context ID like "(1-17,101-112)" and
that caused the modem-helpers to choke.
|
|
* 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
|
|
Also added test cases.
Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
|
|
GSM 07.07 CREG=2 unsolicited pattern.
Added testcase for Thuraya XT.
Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
|
|
Add testcase for Thuraya XT.
Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
|
|
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>
|
|
Add a default implementation that queries the real-time clock using the
AT+CCLK? command. Also set AT+CTZU=1 in case a modem requires it.
|
|
We shouldn't rely on the caller to cleanup intermediate results when returning
an error.
|
|
|
|
This patch fixes memory leaks in unit tests detected by LeakSanitizer.
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=708983
|
|
|
|
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'
|
|
Instead of just a mask of MMModemMode values, we now provide a list of the
allowed and preferred mode combinations supported by the modem. E.g.:
$> sudo mmcli -m 0
-------------------------
Modes | supported: 'allowed: 2g; preferred: none
| allowed: 3g; preferred: none
| allowed: 2g, 3g; preferred: none
| allowed: 2g, 3g; preferred: 2g
| allowed: 2g, 3g; preferred: 3g
| allowed: 4g; preferred: none
| allowed: 2g, 3g, 4g; preferred: none'
|
|
|
|
Adding the 'read' suffix, as they are for CGDCONT? read responses.
|
|
Modems can probably put whatever they want between the quotes for
the operator name, including commas. Handle that.
https://bugzilla.gnome.org/show_bug.cgi?id=701329
|
|
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.
|