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>
Calling the mm_iface_modem_update_unlock_retries function directly from
pin_set_enter_ready caused a notification to be send too early with
invalid number of attempts to unlock on MBIM modems.
The mm_iface_modem_update_unlock_retries is already called for all
modems from send_pin_ready (mm-base-sim.c).
This action allows us to monitor location updates as signaled via the
'Location' property, only available if location signaling has been
explicitly enabled (e.g. with --location-set-enable-signal)
TAC is 3 bytes for NG-RAN as specified in 3GPP TS 38.413 clause
9.3.3.10 and in 3GPP TS 24.501 clause 9.10.3.8.
We'll always print it as 3 bytes in the cli output, as that's also
backwards compatible with the original 2 byte TAC in LTE.
We allow clients to receive asynchronous updates of location
information, e.g. if "location signaling" is explicitly enabled (with
the setup() method).
But if so, we should also allow clients to easily process those
asynchronous updates in the libmm-glib library, instead of requiring
them to run explicit DBus queries to refresh the location information.
These new signaled location APIs allow clients to do so; they can
enable location signaling, and then just wait for the updates to
arrive.
Rework the build_locations() method so that it doesn't take ownership
of the input dictionary. This allows us reusing this method with
dictionaries for which ownership cannot be transferred.
If we return a reference to the internal array in
ensure_internal_supported_storages() and then we free the array
unconditionally in the caller, the next time we call it, the array
would be valid, but it would be fully empty.
Currently, we are not increasing the reference counter of the QrtrNode
when creating a PortQmi for a QRTR port, and we are clearing the object
when disposing the port.
The signal definition is:
<signal name="StateChanged">
<arg name="old" type="i" />
<arg name="new" type="i" />
<arg name="reason" type="u" />
</signal>
So the first two arguments need to be adjusted.
Without this change, the test was failing for me:
(/build/source/tools/tests/.libs/lt-test-stub:77030): GLib-GObject-CRITICAL **: 15:05:35.276: ../gobject/gsignal.c:3167: value for 'gint' parameter 0 for signal "state-changed" is of type 'guint'
==4263== 747 (72 direct, 675 indirect) bytes in 3 blocks are definitely lost in loss record 5,739 of 5,787
==4263== at 0x4842839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4263== by 0x50C6DE8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x50DDFF1: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x50B8EB9: g_list_prepend (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x27CE4C: mm_3gpp_parse_cgdcont_read_response (mm-modem-helpers.c:1845)
==4263== by 0x1E5485: profile_manager_cgdcont_query_ready (mm-broadband-modem.c:10200)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x18605E: at_command_ready (mm-base-modem-at.c:538)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x25ADFA: serial_command_ready (mm-port-serial-at.c:393)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x254752: command_context_complete_and_free (mm-port-serial.c:141)
