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.
If we remove the current element being iterated in the GList, we can
no longer call g_list_next() on it. Ensure we keep a valid pointer to
the next element in the list before removing the current one.
adding bandwidth information in mm-dbus interface
for the serving cell. In serving cell, the details
on whether the pcell/scell are from MCS or SCG is
also updated.
Co-author: Shilpa Shivakumar
A network scan with json output currently returns the following:
root@G3-10940 ~ # mmcli -m 0 -J --3gpp-scan --timeout=300 | jq
{
"modem": {
"3gpp": {
"scan-networks": [
"operator-code: 26201, operator-name: TDG, access-technologies: lte, availability: forbidden",
"operator-code: 26203, operator-name: o2 - de, access-technologies: lte, availability: forbidden",
"operator-code: 26202, operator-name: vodafone.de, access-technologies: lte, availability: current"
]
}
}
}
This is a valid JSON, but in order to be able to access the individual
data elements more easily, the line can also be dumped as a json object.
The following commit converts the lines into a JSON obejct, so that it
looks like this:
root@G3-10940 ~ # mmcli -m 0 -J --3gpp-scan --timeout=300 | jq
{
"modem": {
"3gpp": {
"scan-networks": [
{
"operator-code": "26201",
"operator-name": "TDG",
"access-technologies": "lte",
"availability": "forbidden"
},
{
"operator-code": "26203",
"operator-name": "o2 - de",
"access-technologies": "lte",
"availability": "forbidden"
},
{
"operator-code": "26202",
"operator-name": "vodafone.de",
"access-technologies": "lte",
"availability": "current"
}
]
}
}
}
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
It was not possible to read IMEI of modem when SIM was not inserted or
initialization failed due to modem facility locks. To load IMEI, the
3gpp interface need to be initialized before going to FALLBACK_LIMITED.
In Nixpkgs, sysconfdir is not writeable in the sandbox in which
packages are built, so it's important for us to be able to disable
installing example files. (We create configuration files and install
them into /etc separately through our "module system".)
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Some firmware versions return an empty string for the revision when
using the device caps MBIM request, so use AT commands as a fallback
in case this happens.
This commit modifies the QMI DMS Operating Mode indication registration logic.
During the power sequence chance, if a QMI_PROTOCOL_ERROR_MISSING_ARGUMENT error
was returned in "DMS Set Event Report" operation for Operating Mode Reporting failed,
the whole sequence was aborted, leading the modem to be disabled.
<debug> [modem0] Power indication registration request is sent
...
<debug> [modem0] couldn't update power state: Couldn't register for power indications: QMI protocol error (17): 'MissingArgument'
<warn> [modem0] couldn't enable interface: 'Couldn't register for power indications: QMI protocol error (17): 'MissingArgument''
<debug> [modem0] running implicit disable after failed enable...
This commit modifies the logic to properly detect the failure and
continue the sequence without the indications.
Fixes#683
Signed-off-by: Louis-Alexis Eyraud <louis-alexis.eyraud@unabiz.com>
When using qmi uim service from mbim broadband modem, a fallback from using
qmi uim service to normal mbim operations is done every time a call to
qmi_set_primary_sim_slot fails. But this may fall for various reasons,
and a fallback only makes sense when the device does not support that call
Patch reworked by Aleksander Morgado <aleksandermj@chromium.org>
These were disabled to avoid a large spew of deprecation warnings post
GLib 2.44. That might have been too big a hammer, because it made us
miss us of API from newer GLib than we require.
Let's re-enable the warnings and lower the bottom bound instead.
That way we're get warned about use of API that's too new and also be
warned about things that was deprecated long long ago. We may miss
things that got deprecated in favor of better API after 2.44, but that's
unlikely to be an issue and is definitely better than ignoring
everything altogether.
Avoid a deprecation warning with too new glib:
../libmm-glib/mm-common-helpers.c: In function ‘date_time_format_iso8601’:
../libmm-glib/mm-common-helpers.c:1729:5: warning: ‘g_date_time_format_iso8601’ is deprecated: Not available before 2.62 [-Wdeprecated-declarations]
1729 | return g_date_time_format_iso8601 (dt);
| ^~~~~~
This call site is protected by version guards and provides an alternative
implementation in date_time_format_iso8601().
It requires newer glib than we do:
../libmm-glib/mm-common-helpers.c: In function ‘mm_new_iso8601_time’:
../libmm-glib/mm-common-helpers.c:1787:9: warning: ‘g_time_zone_new_offset’ is deprecated: Not available before 2.58 [-Wdeprecated-declarations]
1787 | tz = g_time_zone_new_offset (offset_minutes * 60);
| ^~
In file included from /usr/include/glib-2.0/glib/gdatetime.h:33:
/usr/include/glib-2.0/glib/gtimezone.h:67:25: note: declared here
67 | GTimeZone * g_time_zone_new_offset (gint32 seconds);
| ^~~~~~~~~~~~~~~~~~~~~~
Let's not use the routine with older versions of glib.
ModemManager[562783]: <err> [1673538458.350130] mm_utils_bin2hexstr: assertion 'bin != NULL' failed
ModemManager[562783]: <dbg> [1673538458.350167] [modem0/bearer0] container ID: 0
ModemManager[562783]: <dbg> [1673538458.350201] [modem0/bearer0] app specific info: (null)
Treat it better by only trying to build the app specific info string
if there are contents in the array.
The device may emit a "WDS Profile Changed" indication triggered from
our own "WDS Modify Profile", "WDS Create Profile" or "WDS Delete
Profile" operations, so ensure those are fully ignored so that we
don't emit the "Updated" signal in the ProfileManager interface.
The logic keeps track of the amount of concurrent operations so that
the signal is ignored for as long as there is at least one operation
running.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/687
Otherwise we may use a wrong typelib shared library (the one that
is installed on the system which run the test)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Instead of creating libmm-plugin* and libmm-shared* libraries that are
dlopen()-ed on runtime, allow incorporating all plugins into the
daemon binary itself.
This makes the startup of the daemon much faster and also avoids
issues with builds that require linker namespace isolation.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/674
<wrn> [plugin-manager] could not load shared '/usr/lib/ModemManager/libmm-shared-xmm.so': Missing major version info
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x000055555562b79d in load_external_shared (path=<optimized out>, self=0x5555557b5880) at ../src/mm-plugin-manager.c:1885
1885 if (module && !(*shared_name))
(gdb) p module
$1 = (GModule *) 0x5555557b9670
(gdb) p shared_name
$2 = (const gchar **) 0x0
