Modify the load_model function to use the AT command to get the
model name and display the module name in the model instead of
[vid:pid].
Test on L860 Linux Device, use `mmcli -L`, it can show: "/org/free
desktop/ModemManager1/Modem/0 [Intel] L860-GL-16 LTE Module"
Some modems (e.g. Telit FN990) reports 5G capabilities in CustomDataClass
field of device-caps cid: take this into account when building the
modes according to the data caps.
==109786== 2,798 (96 direct, 2,702 indirect) bytes in 2 blocks are definitely lost in loss record 5,882 of 5,903
==109786== at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==109786== by 0x4A01329: g_malloc (gmem.c:130)
==109786== by 0x4A23F17: g_slice_alloc (gslice.c:1074)
==109786== by 0x4A4B8F8: UnknownInlinedFun (gvariant-core.c:488)
==109786== by 0x4A4B8F8: UnknownInlinedFun (gvariant-core.c:626)
==109786== by 0x4A4B8F8: g_variant_builder_end (gvariant.c:3756)
==109786== by 0x48FD6DC: mm_pco_to_variant (mm-pco.c:251)
==109786== by 0x1AB397: mm_iface_modem_3gpp_update_pco_list (mm-iface-modem-3gpp.c:2274)
==109786== by 0x2306DF: ms_basic_connect_extensions_notification_pco (mm-broadband-modem-mbim.c:5101)
==109786== by 0x2306DF: ms_basic_connect_extensions_notification (mm-broadband-modem-mbim.c:5280)
==109786== by 0x2306DF: device_notification_cb (mm-broadband-modem-mbim.c:5332)
==109786== by 0x4CD3BD6: g_cclosure_marshal_VOID__BOXEDv (gmarshal.c:1686)
==109786== by 0x4CED11B: UnknownInlinedFun (gclosure.c:895)
==109786== by 0x4CED11B: g_signal_emit_valist (gsignal.c:3456)
==109786== by 0x4CED203: g_signal_emit (gsignal.c:3606)
==109786== by 0x50ADA0F: indication_ready (mbim-device.c:870)
==109786== by 0x4B92DD3: g_task_return_now (gtask.c:1232)
An explicit packet service state update request sent during a
connection attempt may end up triggering an explicit re-attach with
the network, which in turn cancels the ongoing connection attempt.
The logic to trigger an explicit attach is now managed by the
Simple.Connect() operation, which will make sure that no new request
is sent if the modem is already attached, so there is no need for this
step in the MBIM connection logic any more.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/622
The uplink and downlink speeds will be exclusively tracked via packet
service indications, and stored within the MBIM modem object.
When the bearer connect result is built, we will include the latest
speeds reported, which may have changed upon the operation to connect
to the network.
If the packet attach operation fails we may still get the response
with a nw_error field telling us a more detailed error reason for the
failure. Try to parse the message and return an error including the
nw_error information.
The foxconn shared utils are only built when MBIM is enabled, and
therefore the dell and foxconn plugins should only expect those shared
utils to be present if MBIM is enabled. The foxconn plugin will be
fully disabled when MBIM is disabled.
The fibocom shared utils are only built when MBIM is enabled, and
therefore the fibocom plugin should not expect them built
unconditionally, they will only be present if MBIM is enabled
Instead of warning about various unimportant things failing that don't
affect functionality, just print the logs in debug level and go on.
E.g. this warning can be completely skipped:
<wrn> [modem0/sim0] couldn't load GID2: Couldn't read data from UIM: QMI protocol error (16): 'NotProvisioned'
Instead of warning about various unimportant things failing that don't
affect functionality, just print the logs in debug level and go on.
E.g. this warning can be completely skipped:
<wrn> [modem0] couldn't load list of own numbers: Couldn't get MSISDN: QMI protocol error (16): 'NotProvisioned'
