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.
Instead of relying on the udev daemon and GUDev to manage the devices reported
by the kernel, we can now run ModemManager relying solely on the kernel events
reported via the new ReportKernelEvent() API. Therefore, the '--no-auto-scan'
option is implicit for the ModemManager daemon when udev is disabled in the
build.
Additionally, a new custom implementation of the kernel device object is
provided, which uses sysfs to load the properties and attributes required in
each kernel device, instead of using a GUdevDevice.
The udev rule files are kept in place, and a simple custom parser is provided
which preloads all rules in memory once and then applies them to the different
kernel objects reported via ReportKernelEvent(), e.g. to set port type hints.
A simple unit test setup is prepared to validate the udev rules during the
`check' Makefile target.
The mm_base_modem_grab_port() now receives a MMKernelDevice directly from the
plugin, which is then stored in the MMPort corresponding to the port.
This means that we have direct access to e.g. all properties set by udev rules
everywhere, and we don't need additional GUdevClient objects (e.g. like the one
used in the Huawei plugin to detect NDISDUP support during runtime).
For virtual ports (e.g. generated during unit tests), we have a new 'generic'
kernel device object which just provides the values from the kernel device
properties given during its creation.
We try to combine in common envvars the compiler and linker flags shared by the
different components, and where possible, also re-using the implicit AM_CFLAGS
and AM_LDFLAGS variables that automake provides, and which apply to all objects
being built in the same Makefile.am.
The internal libmodem-helpers.la library is also renamed to libhelpers.la
* 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>
Build all targets, except for CLI tools (mmcli, uml290), with special
flags needed for collecting code coverage information when the build has
been configured with --enable-code-coverage.
Three new targets are available in the top build directory:
- `check-code-coverage' runs the test suite and generates a code
coverage report,
- `code-coverage-capture' generates a code coverage report from already
collected data, which can come in handy when one wants to see code
paths touched by a particular test,
- `code-coverage-clean' removes the collected coverage data and the
generated reports.
The QCDM port commands are never cached, so remove the option from the command()
method. Will also simplify command caching afterwards as it will be an AT-only
thing.
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"
Changes being:
* Don't rely on the band preference TLVs presence. The band preference TLVs are
always given, even if the modem doesn't support the specific capability right
away. E.g. a GSM/UMTS/LTE modem configured with 'gsm-umts' capability (no
'lte') still shows the LTE band preference TLV in the SSP responses.
* Don't automatically add LTE as current capability. We needed this when we
were not able to change capabilities, so that we didn't lose the ability to
set 4G mode as allowed.
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'
For loading current capabilities we use a mix of "Technology Preference" (TP),
"System Selection Preference" (SSP) and DMS-reported capabilities. But, as we
also use TP and SSP for allowed modes, it may be the case that we end up
leaving 4G out of the allowed modes, which afterwards will make the modem not
report LTE as current capabilitiy, as TP/SSP don't include LTE.
So, just assume LTE is a current capability if DMS-reported capabilities include
it. We can really do this because LTE is the only 4G technology, the same logic
wouldn't apply correctly for 2G or 3G (due to having different techs for 3GPP
and 3GPP2).
Aleksander Morgado
Dan Williams
Carlo Lobrano
Thomas Sailer
Nick Stevens
Jason Simmons
Jakub Sitnicki
Ben Chan
Aleksander Morgado