Age | Commit message (Collapse) | Author |
|
No users left for the getter that takes a reference after a port of
MMBaseModemAT to GTask.
peek_cancellable() is used instead, because the GTask constructor
takes a reference itself.
|
|
Use GTask API in place of the deprecated GSimpleAsyncResult.
|
|
Use GTask API in place of the deprecated GSimpleAsyncResult.
|
|
This will make it slightly easier to port mm_port_serial_at_command() to
use GTask, since we won't have to keep a pointer to the result in GTask
after _finish() has been called.
In most cases the caller needs the value anyway, so this doesn't add too
much hasle.
|
|
Use GTask API in place of the deprecated GSimpleAsyncResult.
|
|
Whenever an explicit signal refresh was requested we would flag the
check as ongoing but never reset the flag, so it would never attempt
to reload it again.
Fixes 0080ed612d0a412c5794059a93ed30ca07103b79
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/702
|
|
The personalization feature enum used in "card status" is different to
the one used in other UIM operations like "depersonalization".
libqmi dependency updated to 1.33.6 to ensure we can use the new types.
|
|
|
|
../src/plugins/cinterion/mm-plugin-cinterion.c:65:1: warning: no previous prototype for ‘is_port_already_tagged’ [-Wmissing-prototypes]
65 | is_port_already_tagged (MMPortProbe *probe)
| ^~~~~~~~~~~~~~~~~~~~~~
|
|
The Cinterion plugin is using the output of the SQPORT? to guess which
ports can be used for AT commands and data connection.
Yet at the same time the udev adds port type hints to the Cinterion
modem upon its discovery.
This commit changes the initialization in a way that from now on it
skips sending SQPORT? when the port type hints are already assigned. By
doing this we make sure that the udev port type hints are being used
when they are available. In case they are not the initialization relies
on the outout of SQPORT? as it did do far.
See: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/782
|
|
GCC 13 got unhappy about using an int in place of an enum:
../src/mm-port-qmi.c:241:1: warning: conflicting types for ‘mm_port_qmi_release_client’ due to enum/integer mismatch; have ‘void(MMPortQmi *, QmiService, MMPortQmiFlag)’ {aka ‘void(struct _MMPortQmi *, QmiService, MMPortQmiFlag)’} [-Wenum-int-mismatch]
241 | mm_port_qmi_release_client (MMPortQmi *self,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/mm-port-qmi.c:26:
../src/mm-port-qmi.h:113:10: note: previous declaration of ‘mm_port_qmi_release_client’ with type ‘void(MMPortQmi *, QmiService, guint)’ {aka ‘void(struct _MMPortQmi *, QmiService, unsigned int)’}
113 | void mm_port_qmi_release_client (MMPortQmi *self,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
GCC 13 is unhappy to cast a MMLogLevel to a guint32:
[188/539] Compiling C object src/plugins/test-shared-icera.p/icera_tests_test-modem-helpers-icera.c.o
In file included from ../src/plugins/icera/tests/test-modem-helpers-icera.c:27:
../src/mm-log-test.h:25:1: warning: conflicting types for ‘_mm_log’ due to enum/integer mismatch; have ‘void(void *, const gchar *, const gchar *, const gchar *, guint32, const gchar *, ...)’ {aka ‘void(void *, const char *, const char *, const char *, unsigned int, const char *, ...)’} [-Wenum-int-mismatch]
25 | _mm_log (gpointer obj,
| ^~~~~~~
In file included from ../src/mm-log-test.h:20:
../src/mm-log.h:61:6: note: previous declaration of ‘_mm_log’ with type ‘void(void *, const gchar *, const gchar *, const gchar *, MMLogLevel, const gchar *, ...)’ {aka ‘void(void *, const char *, const char *, const char *, MMLogLevel, const char *, ...)’}
61 | void _mm_log (gpointer obj,
| ^~~~~~~
That's perfectly fine, just use the enum type directly.
|
|
==174467== Invalid read of size 1
==174467== at 0x10B80C: read_bits (mm-sms-part-cdma.c:255)
==174467== by 0x10B886: read_bits (mm-sms-part-cdma.c:260)
==174467== by 0x10DC2F: read_bearer_data_user_data (mm-sms-part-cdma.c:882)
==174467== by 0x10DC2F: read_bearer_data (mm-sms-part-cdma.c:1000)
==174467== by 0x10DC2F: mm_sms_part_cdma_new_from_binary_pdu (mm-sms-part-cdma.c:1180)
==174467== by 0x10DF24: mm_sms_part_cdma_new_from_pdu (mm-sms-part-cdma.c:331)
==174467== by 0x10A91D: common_test_valid_part_from_hexpdu (test-sms-part-cdma.c:114)
==174467== by 0x10B0AC: common_test_valid_part_from_pdu (test-sms-part-cdma.c:126)
==174467== by 0x10B0AC: test_invalid_ascii_user_data (test-sms-part-cdma.c:412)
==174467== by 0x4A0264D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A02B1A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== Address 0x51a6457 is 0 bytes after a block of size 7 alloc'd
==174467== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==174467== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==174467== by 0x10DF06: mm_sms_part_cdma_new_from_pdu (mm-sms-part-cdma.c:325)
==174467== by 0x10A91D: common_test_valid_part_from_hexpdu (test-sms-part-cdma.c:114)
==174467== by 0x10B0AC: common_test_valid_part_from_pdu (test-sms-part-cdma.c:126)
==174467== by 0x10B0AC: test_invalid_ascii_user_data (test-sms-part-cdma.c:412)
==174467== by 0x4A0264D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==174467== by 0x4A02B1A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
|
|
Same fix also applied to latin encoded text as it also makes sense there.
==158856== Invalid read of size 1
==158856== at 0x10B814: read_bits (mm-sms-part-cdma.c:257)
==158856== by 0x10DB07: read_bearer_data_user_data (mm-sms-part-cdma.c:878)
==158856== by 0x10DB07: read_bearer_data (mm-sms-part-cdma.c:990)
==158856== by 0x10DB07: mm_sms_part_cdma_new_from_binary_pdu (mm-sms-part-cdma.c:1170)
==158856== by 0x10DE54: mm_sms_part_cdma_new_from_pdu (mm-sms-part-cdma.c:333)
==158856== by 0x10A916: common_test_invalid_part_from_hexpdu (test-sms-part-cdma.c:90)
==158856== by 0x10A916: common_test_invalid_part_from_pdu (test-sms-part-cdma.c:104)
==158856== by 0x4A0264D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A02B1A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A02BBC: g_test_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x10A509: main (test-sms-part-cdma.c:595)
==158856== Address 0x51a627b is 0 bytes after a block of size 11 alloc'd
==158856== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==158856== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==158856== by 0x10DE36: mm_sms_part_cdma_new_from_pdu (mm-sms-part-cdma.c:327)
==158856== by 0x10A916: common_test_invalid_part_from_hexpdu (test-sms-part-cdma.c:90)
==158856== by 0x10A916: common_test_invalid_part_from_pdu (test-sms-part-cdma.c:104)
==158856== by 0x4A0264D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A023B4: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A02B1A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856== by 0x4A02BBC: g_test_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==158856==
|
|
GLib-CRITICAL **: 21:21:51.419: g_convert: assertion 'str != NULL' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff7db3e82 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff7db3e82 in g_logv () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff7db40ef in g_log () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7d8a5da in g_convert () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00005555555592cf in read_bearer_data_user_data (log_object=0x0, subparameter=<optimized out>, sms_part=0x555555578000)
at ../src/mm-sms-part-cdma.c:929
#4 read_bearer_data (log_object=0x0, parameter=<optimized out>, sms_part=0x555555578000) at ../src/mm-sms-part-cdma.c:982
#5 mm_sms_part_cdma_new_from_binary_pdu
|
|
ERROR:../src/mm-sms-part-cdma.c:678:read_cause_codes: assertion
failed: (parameter->parameter_id == PARAMETER_ID_BEARER_REPLY_OPTION)
|
|
[debug] parsing PDU (0)...
[debug] no SMSC address given
[debug] submit type PDU detected
[debug] message reference: 1
[debug] address size: 1 digits (1 bytes)
[debug] number parsed: 00
[debug] validity available, format relative
[debug] PID: 0
[debug] user data encoding is GSM7
[debug] user data length: 0 elements
[debug] user data length: 0 bytes
==125780== Command: ./build/test/mmsmspdu --pdu=00F101010C0000000000 --verbose
==125780==
==125780== Invalid read of size 1
==125780== at 0x10B422: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:698)
==125780== by 0x10BF57: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:368)
==125780== by 0x10A44D: main (mmsmspdu.c:242)
==125780== Address 0x519988a is 0 bytes after a block of size 10 alloc'd
==125780== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==125780== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==125780== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==125780== by 0x10BF36: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:362)
==125780== by 0x10A44D: main (mmsmspdu.c:242)
|
|
==101461== Command: ./build/test/mmsmspdu --pdu=004100010100014B00002E --verbose
==101461==
[debug] parsing PDU (0)...
[debug] no SMSC address given
[debug] submit type PDU detected
[debug] message reference: 0
[debug] address size: 1 digits (1 bytes)
[debug] number parsed: 00
[debug] PID: 1
[debug] user data encoding is GSM7
[debug] user data length: 0 elements
[debug] user data length: 0 bytes
[debug] decoding SMS text with 4294967294 elements
Based on a patch from Michal Mazur <mkm@semihalf.com>.
|
|
address
Before the actual number digits there is always a Type of Address byte
that we were not considering during the size check.
[debug] parsing PDU (0)...
[debug] no SMSC address given
[debug] deliver type PDU detected
[debug] address size: 1 digits (1 bytes)
==90832== Command: ./build/test/mmsmspdu --pdu=001C011C --verbose
==90832==
==90832== Invalid read of size 1
==90832== at 0x10AC90: sms_semi_octets_to_bcd_string (mm-sms-part-3gpp.c:71)
==90832== by 0x10AC90: sms_decode_address (mm-sms-part-3gpp.c:157)
==90832== by 0x10B0C5: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:512)
==90832== by 0x10BF77: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:368)
==90832== by 0x10A44D: main (mmsmspdu.c:242)
==90832== Address 0x5199874 is 0 bytes after a block of size 4 alloc'd
==90832== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==90832== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==90832== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==90832== by 0x10BF56: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:362)
==90832== by 0x10A44D: main (mmsmspdu.c:242)
|
|
[debug] parsing PDU (0)...
[debug] no SMSC address given
[debug] status report type PDU detected
[debug] message reference: 191
[debug] address size: 0 digits (0 bytes)
==78906== Command: ./build/test/mmsmspdu --pdu=000ABF00 --verbose
==78906==
==78906== Invalid read of size 1
==78906== at 0x10AA80: sms_decode_address (mm-sms-part-3gpp.c:132)
==78906== by 0x10AF7C: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:507)
==78906== by 0x10BE17: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:368)
==78906== by 0x10A44D: main (mmsmspdu.c:202)
==78906== Address 0x5199874 is 0 bytes after a block of size 4 alloc'd
==78906== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==78906== by 0x49DF6C0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.2)
==78906== by 0x48ABD24: mm_utils_hexstr2bin (mm-common-helpers.c:1884)
==78906== by 0x10BDF6: mm_sms_part_3gpp_new_from_pdu (mm-sms-part-3gpp.c:362)
==78906== by 0x10A44D: main (mmsmspdu.c:202)
|
|
|
|
Always prefer the operation error when the nw_error is not set (has
value MBIM_NW_ERROR_NONE). If the activation state is ACTIVATED or
ACTIVATING then the behavior doesn't change.
|
|
|
|
|
|
When QCDM is not required we don't run an explicit QCDM port probing
operation.
In this case, though, we should not assume that the port is QCDM
capable, even if it is also flagged as ignored.
Instead, we'll flag the port as QCDM capable and ignored only if there
was a udev port type hint associated to the port. Otherwise, we'll
report the port as not being QCDM capable, and the port won't even be
reported in the list of ports as its type is unknown.
|
|
|
|
The supported Quectel modules are usually QMI based and therefore
very new, there is no real requirement to support QCDM based
management.
|
|
The supported broadmobi modules are usually QMI based and therefore
very new, there is no real requirement to support QCDM based
management.
|
|
The QCDM ports are not strictly required in the Sierra plugin, as this
plugin deals exclusively with QMI and MBIM capable devices.
|
|
Happens when we boot without a SIM card inserted:
ModemManager[12065]: <dbg> [1679912011.887410] [ttyACM2/at] --> 'AT+CLCK="PC",2<CR>'
ModemManager[12065]: <dbg> [1679912011.905401] [ttyACM2/at] <-- '<CR><LF>+CLCK: 0<CR><LF><CR><LF>OK<CR><LF>'
(ModemManager:12065): GLib-GObject-CRITICAL **: 12:13:31.905: invalid (NULL) pointer instance
|
|
|
|
|
|
reached
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/646
|
|
The feature/rx_offload and feature/tx_offload sysfs attributes specify
which offload settings should be used when creating new links.
|
|
|
|
operations"
This reverts commit dad3e8274723805e3957f166ba158a37cf6a96ec.
Disabling profile change indications just before doing our profile
updates and re-enabling them just after is not enough. The modem may
still emit the profile change indication right after, so all this
logic is unnecessary.
|
|
|
|
GError structure may not be initialized after execution of
mm_3gpp_parse_cgdcont_read_response() and accessing it's
fields will cause a segmentation fault.
|
|
src/mm-iface-modem-signal.c:99:27: warning: unused variable 'current_time' [-Wunused-variable]
g_autoptr(GDateTime) current_time = NULL;
^
|
|
src/mm-sim-mbim.c:1134:30: warning: unused variable 'request' [-Wunused-variable]
g_autoptr(MbimMessage) request = NULL;
^
|
|
Just ignoring the received indications is not enough, because they
could arrive after the operation response has been processed.
We now explicitly disable the indications by reconfiguring the modem
before and after every profile update operation triggered by our own
logic.
|
|
When Telit FN990 is integrated through PCIe, but also USB lines are
available, ModemManager will consider the port on the USB composition
as a different modem:
oem@sw-test:~$ mmcli -L
/org/freedesktop/ModemManager1/Modem/1 [telit] FN990A40
/org/freedesktop/ModemManager1/Modem/0 [Telit] FN990A40
oem@sw-test:~$ mmcli -m 0
<snip>
| equipment id: 359172390022295
--------------------------------
System | device: /sys/devices/pci0000:00/0000:00:14.0/usb2/2-5
| drivers: option
| plugin: telit
| primary port: ttyUSB0
| ports: ttyUSB0 (at)
oem@sw-test:~$ mmcli -m 1
<snip>
| equipment id: 359172390022295
-----------------------------------
System | device: /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0
| drivers: mhi-pci-generic
| plugin: telit
| primary port: wwan0mbim0
| ports: wwan0 (net), wwan0at0 (at), wwan0at1 (at),
| wwan0mbim0 (mbim), wwan0nmea0 (ignored), wwan0qcdm0 (ignored)
Ignore composition 0x1075, since it should not be used by ModemManager
and can only show when PCIe is used.
|
|
|
|
On MBIM modems that do not support mbimex v2, extra steps are required
to retrieve 3G/4G signal quality markers from the modem when using
thresholds to trigger signal quality indications.
|
|
[1/2] Compiling C object src/ModemManager.p/mm-base-manager.c.o
../src/mm-base-manager.c: In function ‘remove_device_inhibition’:
../src/mm-base-manager.c:1127:20: warning: declaration of ‘l’ shadows a previous local [-Wshadow]
1127 | GList *l;
| ^
../src/mm-base-manager.c:1116:16: note: shadowed declaration is here
1116 | GList *l;
| ^
|
|
Signed-off-by: QuectelDuke <duke.xin@quectel.com>
|
|
Ensure we don't assert when processing an unexpected response.
We were not correctly handling the case where g_match_info_matches()
was not succeeding.
0x00007d8be96cc462 (libc.so.6 + 0x00028462) abort
0x00007d8be995ff01 (libglib-2.0.so.0 - gtestutils.c: 3253) g_assertion_message
0x00007d8be995ff64 (libglib-2.0.so.0 - gtestutils.c: 3279) g_assertion_message_expr
0x00007d8be858086a (libmm-shared-xmm.so - mm-modem-helpers-xmm.c: 467) mm_xmm_parse_xact_query_response
0x00007d8be857d4e0 (libmm-shared-xmm.so - mm-shared-xmm.c: 310) xact_query_bands_ready
0x00007d8be9a79463 (libgio-2.0.so.0 - gsimpleasyncresult.c: 802) g_simple_async_result_complete
0x00005c8d2a11e9b9 (ModemManager - mm-base-modem-at.c: 538) at_command_ready
0x00007d8be9a79463 (libgio-2.0.so.0 - gsimpleasyncresult.c: 802) g_simple_async_result_complete
0x00005c8d2a19376b (ModemManager - mm-port-serial-at.c) serial_command_ready
0x00007d8be9a79463 (libgio-2.0.so.0 - gsimpleasyncresult.c: 802) g_simple_async_result_complete
0x00005c8d2a18f93f (ModemManager - mm-port-serial.c: 139) command_context_complete_and_free
0x00005c8d2a192985 (ModemManager - mm-port-serial.c: 753) port_serial_got_response
0x00005c8d2a192dff (ModemManager - mm-port-serial.c: 924) common_input_available
0x00007d8be993e3fc (libglib-2.0.so.0 - gmain.c: 3417) g_main_context_dispatch
0x00007d8be993e704 (libglib-2.0.so.0 - gmain.c: 4211) g_main_context_iterate
0x00007d8be993e978 (libglib-2.0.so.0 - gmain.c: 4411) g_main_loop_run
0x00005c8d2a105e66 (ModemManager - main.c: 217) main
0x00007d8be96cc6c5 (libc.so.6 + 0x000286c5) __libc_init_first
0x00007d8be96cc781 (libc.so.6 + 0x00028781) __libc_start_main
0x00005c8d2a105b80 (ModemManager + 0x00061b80) _start
|
|
If the device is not fully removed from the system during inhibition
and port additions happen, we reach a state where the MMDevice object
is still tracked by ModemManager and we also have new port additions
tracked that will require explicit port probings before a new modem
object can be created.
Solve this mixup by faking the removal of all existing device ports,
which will end up completely removing hte MMDevice, so that new port
additions reported afterwards also involve the full device probing
process triggered by the plugin manager.
The issue could be reproduced easily on a MBIM device that also
exposed TTYs, as follows:
* mmcli -m a --inhibit, leave it running
* rmmod cdc_mbim && sleep 5 && modprobe cdc_mbim (so that the
cdc-wdm and net ports go away from the system but NOT the TTYs.)
* Cltr+C to stop the inhibit in the mmcli call.
ModemManager would assert as follows:
0x000079918bcf2a3f (libc.so.6 + 0x00087a3f) pthread_key_delete
0x000079918bca7c6c (libc.so.6 + 0x0003cc6c) gsignal
0x000079918bc93462 (libc.so.6 + 0x00028462) abort
0x000079918bf26f03 (libglib-2.0.so.0 - gtestutils.c: 3253) g_assertion_message
0x000079918bf26f66 (libglib-2.0.so.0 - gtestutils.c: 3279) g_assertion_message_expr
0x0000594ff1093d0c (ModemManager - mm-base-manager.c: 1110) remove_device_inhibition
0x0000594ff1093968 (ModemManager - mm-base-manager.c: 1247) inhibit_device_auth_ready
0x000079918c0536a8 (libgio-2.0.so.0 - gtask.c: 1230) g_task_return_now
0x000079918c0536db (libgio-2.0.so.0 - gtask.c: 1244) complete_in_idle_cb
0x000079918bf053fc (libglib-2.0.so.0 - gmain.c: 3417) g_main_context_dispatch
0x000079918bf05704 (libglib-2.0.so.0 - gmain.c: 4211) g_main_context_iterate
0x000079918bf05978 (libglib-2.0.so.0 - gmain.c: 4411) g_main_loop_run
0x0000594ff108de66 (ModemManager - main.c: 217) main
0x000079918bc936c5 (libc.so.6 + 0x000286c5) __libc_init_first
0x000079918bc93781 (libc.so.6 + 0x00028781) __libc_start_main
0x0000594ff108db80 (ModemManager + 0x00061b80) _start
|
|
The Tethering context type UUID was defined by Microsoft in its
extensions as `5e4e0601-48dc-4e2b-acb8-08b4016bbaac` (along with
others like Admin, Xcap, App and EmergencyCalling), see
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/mb-provisioned-context-operations.
These UUIDs are expected to be usable only if the modem supports
`MBIM_CID_MS_PROVISIONED_CONTEXT_V2` (CID=1) in the Basic Connect
Extensions service (3d01dcc5-fef5-4d05-0d3abef7058e9aaf).
If the modem doesn't support these, we should try to fallback to a
more generic APN type automatically, e.g. "Internet", which was
defined in MBIM 1.0 and should always be supported.
There should be no problem in a modem to have 2 separate PDN
connections with the same context type.
|
|
|