| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
Implement the detailed signal info interface for some Huawei 3GPP modems
including those based on HiSilicon chipsets like the E3276. Known not to
work on many Qualcomm-based Huawei modems like E392, E397, and E367 as
they don't support the ^HCSQ command, but they do support QMI and so
have access to the extended signal interface via QMI.
|
|
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
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=94364
|
|
We should really consider errors if we expect that the regex string may not
compile; but in this case the pattern is fixed, so should never happen.
|
|
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>
|
|
We were trying to load the generic modes supported reported by either *CNTI=2 or
AT+WS46=?, so that then we could filter out the MBM-specific modes unsupported.
But, this may not be ideal, as both these two commands may fail:
[mm-broadband-modem.c:1612] modem_load_supported_modes(): loading supported modes...
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT*CNTI=2<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1546] supported_modes_cnti_ready(): Generic query of supported 3GPP networks with *CNTI failed: 'Unknown error'
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT+WS46=?<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1494] supported_modes_ws46_test_ready(): Generic query of supported 3GPP networks with WS46=? failed: 'Unknown error'
[mm-iface-modem.c:3974] load_supported_modes_ready(): couldn't load Supported Modes: 'Couldn't retrieve supported modes'
Instead, we'll ask the modem for the list of modes supported, and return that
directly.
|
|
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 response is already managed by the generic AT serial port and translates
it into a proper error. This change also avoids the Call.Start() call to report
a timeout in the serial port, instead we get a proper no-carrier error.
Before:
$ sudo mmcli -m 0 --voice-create-call="number=12345678"
Successfully created new call:
/org/freedesktop/ModemManager1/Call/1 outgoing (unknown)
$ sudo mmcli -o 1 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Serial.ResponseTimeout: Serial command timed out'
After:
$ sudo mmcli -m 0 --voice-create-call="number=12345678"
Successfully created new call:
/org/freedesktop/ModemManager1/Call/1 outgoing (unknown)
$ sudo mmcli -o 1 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Connection.NoCarrier: No carrier'
|
|
|
|
|
|
|
|
|
|
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.
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1183250
|
|
Stupid me, introduced a bug when manually writing the previous patch.
:/
|
|
My modem (Samsung GI B3740) responded "IPV4" to "CGDCONT=?". This was
not handled in mm-modem-helpers.c. The obvious fix was to return
MM_BEARER_IP_FAMILY_IPV4.
|
|
We shouldn't rely on the caller to cleanup intermediate results when returning
an error.
|
|
Allow whitespaces added in several places, like between the comma and the index,
which is what the Cinterion PHS8 does:
<CR><LF>+CMTI: "MT", 5<CR><LF>
|
|
|
|
This patch fixes the following crash, which happens when
MMBroadbandBearer tries to parse the NULL response of a failed +CGDCONT?
query. It also fixes a leak in parse_pdp_list where it fails to free the
GError object return by mm_3gpp_parse_cgdcont_read_response.
Thread 0 *CRASHED* ( SIGSEGV @ 0x00000000 )
0x7feb15564c11 [ModemManager] - mm-modem-helpers.c:850 mm_3gpp_parse_cgdcont_read_response
0x7feb15518e51 [ModemManager] - mm-broadband-bearer.c:927 parse_pdp_list
0x7feb1551ada2 [ModemManager] - mm-base-modem-at.c:189 at_sequence_parse_response
0x7feb151d4b86 [libgio-2.0.so.0.3400.3] - gsimpleasyncresult.c:775 g_simple_async_result_complete
0x7feb1556e223 [ModemManager] - mm-port-serial-at.c:355 serial_command_ready
0x7feb151d4b86 [libgio-2.0.so.0.3400.3] - gsimpleasyncresult.c:775 g_simple_async_result_complete
0x7feb1556a834 [ModemManager] - mm-port-serial.c:141 command_context_complete_and_free
0x7feb1556bc26 [ModemManager] - mm-port-serial.c:734 port_serial_got_response
0x7feb1556c51a [ModemManager] - mm-port-serial.c:758 port_serial_timed_out
0x7feb1508cc33 [libglib-2.0.so.0.3400.3] - gmain.c:4026 g_timeout_dispatch
0x7feb1508c087 [libglib-2.0.so.0.3400.3] - gmain.c:2715 g_main_context_dispatch
0x7feb1508c437 [libglib-2.0.so.0.3400.3] - gmain.c:3290 g_main_context_iterate
0x7feb1508c891 [libglib-2.0.so.0.3400.3] - gmain.c:3484 g_main_loop_run
0x7feb1550ad16 [ModemManager] - main.c:154 main
0x7feb14a9e9c6 [libc-2.15.so] - libc-start.c:234 __libc_start_main
0x7feb1550a808 [ModemManager + 0x00023808
|
|
Some modems (e.g. ZTE MF190) report UMTS access technology as "3G":
--> 'AT+ZPAS?<CR>'
<-- '<CR><LF>+ZPAS: "3G","CS_PS"<CR><LF><CR><LF>OK<CR><LF>'
|
|
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.
|
|
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'
|
|
|
|
We want to expose in the Modem interface the list of supported IP families, and
the easiest way to do so is to have the IP family as flags, and provide in the
interface a single enum.
Also, a value of 0 for a MMBearerIpFamily specifies that no flags are set, so
just rename it to 'NONE'.
And add a new 'ANY' value which sets all flags to 1.
|
|
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
|
|
#697372)
The GetNetworkTime() response is defined to be an ISO8601 string, which
is in turn defined to be in local time. Make sure that's reflected in
the documentation, and append the timezone offset to UTC where we have
it.
Oddly, Icera devices return their time info in UTC with an offset to
the local timezone, so we have to jump through some hoops there to
convert the response to localtime based on the reported offset.
Some additional fixes by Aleksander Morgado <aleksander@lanedo.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=697372
|
|
|
|
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.
|
|
Some Huawei modems report these, and we may use the generic helper
in the future.
|
|
We can skip additional UTF-8 validity check when parsing operator.
mm_charset_take_and_convert_to_utf8() already does a UTF-8 validity check
internally before returning the string, so it's pointless to do a new one
on the returned string.
Plus, mm_charset_take_and_convert_to_utf8() may really return NULL, which
would end up in segfaulting as g_utf8_validate() expects always a non-NULL
string.
Based on 219424a6e2d017491a05ecbed661bccde3f991ef (MM_06 branch)
|
|
In QMI modems the logic behind supported and current bands is completely
separated in different services (DMS vs NAS). Actually, the list reported by NAS
as current band preferences seems to include more values than the ones reported
by DMS as supported bands (e.g. CDMA bands are reported even if the firmware
image is GSM/HSPA only).
So, just clean up the list of current preferred bands so that no more than those
given as supported is used.
|
|
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
|
|
Some modems report "Unknown" as the operator name when failed to obtain
the actual value:
--> 'AT+COPS=3,0;+COPS?<CR>'
<-- '<CR><LF>+COPS: 0,0,"Unknown",0<CR><LF><CR><LF>OK<CR><LF>'
This patch prevents "Unknown" from being treated as a valid operator name.
|
|
Some devices, e.g. ZTE MF820D, seem to prefix the `AT+CGMM?' response with the
`+CGMM:' string, resulting in the following model string being loaded:
model: '+CGMM: "MF820D"'
Avoid this by:
1) Removing the expected prefixes.
2) Unquoting the resulting string.
Reported by: Marius Kotsbak <marius.kotsbak@gmail.com>
|
