See log from a SARA-R410M-02B-01 before the change:
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.012330] [modem0/ttymxc4/at] --> 'AT+UBANDSEL?<CR>'
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.026831] [modem0/ttymxc4/at] <-- '<CR><LF>ERROR<CR><LF>'
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.027113] [modem0/ttymxc4/at] operation failure: 100 (Unknown error)
Feb 01 05:40:01 unit ModemManager[304]: <warn> [1612158001.027298] [modem0] couldn't load current bands: Unknown error
Backed by SARA-R4 series AT commands manual, no reference to +UBANDSEL
in the manual at all.
Log after the change:
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500845] [modem0] (u-blox) support configuration found for 'SARA-R410M-02B'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500961] [modem0] (u-blox) band update requires explicit unregistration
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.501052] [modem0] (u-blox) UACT based band configuration unsupported
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.501141] [modem0] (u-blox) UBANDSEL based band configuration unsupported
Fixes: 437fb830c8 ("ublox,helpers: assume all SARA/LARA devices require COPS")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
The SARA-R410M-02B-01 only supports values 7 and 8, log excerpt:
Feb 01 05:40:00 unit ModemManager[304]: <debug> [1612158000.826046] [modem0/ttymxc4/at] --> 'AT+URAT=?<CR>'
Feb 01 05:40:00 unit ModemManager[304]: <debug> [1612158000.833596] [modem0/ttymxc4/at] <-- '<CR><LF>+URAT: (7-8),(7-8)(7-8)<CR><LF><CR><LF>OK<CR><LF>'
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.833992] [modem0] (u-blox) unexpected AcT value: 7
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.834096] [modem0] (u-blox) unexpected AcT value: 8
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.834193] [modem0] couldn't load supported modes: No combinations built from +URAT=? response
The SARA-R4 series AT commands manual (and also the SARA-R5 AT commands
manual) lists them like this:
- 7: LTE Cat M1
- 8: LTE Cat NB1
After the change, log looks like this:
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.490627] [modem0/ttymxc4/at] --> 'AT+URAT?<CR>'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.499994] [modem0/ttymxc4/at] <-- '<CR><LF>+URAT: 7,8<CR><LF><CR><LF>OK<CR><LF>'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500433] [modem0] (u-blox) current allowed modes retrieved: 4g
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500561] [modem0] (u-blox) current preferred modes retrieved: 4g
Signed-off-by: Alexander Dahl <ada@thorsis.com>
We can safely cast the data in a GArray to gpointer first, and then
to the pointer type we require.
ublox/mm-modem-helpers-ublox.c: In function 'parse_bands_from_string':
ublox/mm-modem-helpers-ublox.c:1612:48: error: cast increases required alignment of target type [-Werror=cast-align]
tmpstr = mm_common_build_bands_string ((MMModemBand *)(bands->data), bands->len);
^
If load_current_bands_finish() returns a NULL GArray, we must set the
GError or otherwise the daemon will segfault when the caller
dereferences the GError:
current_bands = MM_IFACE_MODEM_GET_INTERFACE (self)->load_current_bands_finish (self, res, &error);
if (!current_bands) {
/* Errors when getting current bands won't be critical */
mm_warn ("couldn't load current Bands: '%s'", error->message);
g_error_free (error);
}
This may happen with an empty but balid +UACT response, e.g.:
AT+UACT?
+UACT: ,,,
OK
Or when it replies a full empty string:
AT+UACT?
OK
This patch fixes several invalid checks like this:
array[i] && i < G_N_ELEMENTS (array)
which should instead be:
i < G_N_ELEMENTS (array) && array[i]
to avoid an out-of-bounds access of the array.
Fixes: c1aa658802
We were filtering the 4G bands supported by the module when parsing
+UBANDSEL responses, e.g. so that we would not reply unsupported bands
for a given ubandsel value.
But we need the same filtering in 2G and 3G bands, because for example
some modules may support a specific 4G band with a given ubandsel
value, but NOT the associated 3G band. E.g. the TOBY-R200 supports
EUTRAN-4 but not UTRAN-4.
We cannot have the ubandsel value comparision inside the for(;;) stop
conditions, because that would mean the loop would stop whenever the
comparison fails. We want to look for a value, so we need to loop the
whole array and stop once we find it only.
Make mm_ublox_get_support_config() return FALSE only when GError is
set. And also, prepare a preload_support_config() method to be run
before using any information from the support configuration (i.e.
don't do it in load_supported_bands(), do it in load_current_bands()
or in set_current_bands().
The u-blox plugin was originally written to support the TOBY-L4 only.
This caused issues with mmcli reporting the correct supported and
current bands because the logic was based only for the TOBY-L4 and
the AT commands used in the implementaion are only supported by
a couple of modems.
There is now a hard-coded modem list that contains the supported bands
and the supported modes. A hard-coded list was chosen over a logic
based list because ublox modems only report the frequency of the bands
they support in the current mode they are in. For further justification,
the reported frequency could relate to multiple bands that are not all
supported by the modem, and not all the supported bands are always caught
depending on the mode the modem is in (e.g. 2G, 3G, 4G). The only
realiable way to retrieve the correct supported bands is to have the list
hard-coded. Based off of the modem, the code chooses whether it is
appropriate to issue +UACT or +UBANDSEL to retrieve the current bands list.
Additionally, the appropriate AT command of +CFUN=4 or +COPS=2 is chosen
to detach from the network when the mmcli --set-current-bands command is
issued. The new setup also adds a header file that contains the modem list.
This should make adding support for future additional modems easier as long
as future modems stick to the same AT command interface that is currently
supported by the plugin.
The 'any' mode refers to the mode which includes most access
technologies and where none of them is preferred.
Fix the logic so that all combinations with one technology preferred
over the others are ignored, instead of the other way around.
Fixes assertion with the 4G-only LARA R204.
ModemManager[424]: <debug> [-192499452.090358] (ttyACM0): --> 'AT+URAT=?<CR>'
ModemManager[424]: <debug> [-192499452.092150] (ttyACM0): <-- '<CR><LF>+URAT: (3)<CR><LF><CR><LF>OK<CR><LF>'
**
ERROR:ublox/mm-modem-helpers-ublox.c:817:mm_ublox_get_modem_mode_any: assertion failed: (any != MM_MODEM_MODE_NONE)
Reported-by: Matthew Starr <mstarr@hedonline.com>
This patch fixes an uninitialized variable issue in
mm_ublox_parse_ugcntrd_response_for_cid(), which uses an uninitialized
`match_info' when `in_cid' is invalid.
The implementation uses +UGCNTRD=? to query whether the per-PDP context
statistics are supported by the device, and if they are, +UGCNTRD is used to
query them.
We only process the statistics for the specific CID we're using.
The parser returns only the results for the CID being specified as input. This
is so that we can just query the statistics of the CID currently in use by the
bearer.
Changing current allowed/preferred modes requires the device to be in low-power
mode, so we will make sure we return an error if any power operation is already
ongoing when a new one is requested.
AT+URAT=? provides the format expected, but looks like it isn't implemented
differently for the different u-blox devices seen, so we need an additional
level of filtering which currently is applied per device model string.
