Seen on a Qualcomm-based Quectel EG915Q on the diag port:
ModemManager[34547]: <dbg> [1732077670.330527] [ttyUSB0/at] <-- ' \0\0\0\8\0\0\0\2\0\0\0\0`%\160$"\6\169\128\200\1\30\197\142\0G\184\225\128\0\1+\127\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254\255\255\255\255\255\255\255\254'
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If by any chance the same ports needs to go through AT and
QMI/MBIM probing, make sure the serial port created during
AT probing is closed before starting the QMI/MBIM probing.
The hotplugged flag was added to simplify modem probe on first time it
is created. Before the re-probe it must be set to FALSE to destroy all
existing netlink interfaces and force full reconfiguration.
This adds
```
$ mmcli -m 0 --cell-broadcast-list-cbm
/org/freedesktop/ModemManager1/CBM/0 (received)
/org/freedesktop/ModemManager1/CBM/0 (received)
$ mmcli -m 0 --cell-broadcast-delete-cbm=0
successfully deleted CBM from modem
$ mmcli -m 0 --cbm 0
--------------------------
General | path: /org/freedesktop/ModemManager1/CBM/1
--------------------------
Content | text: This is a test of the Ontario Alert Ready System. There is no danger to your health or safety
--------------------------
Properties | update: 0
| message code: 0
```
Signed-off-by: Guido Günther <agx@sigxcpu.org>
The CBMs are read via unsolicted events for which we register
an event handler.
We don't enable unsolicted events explicitly as this already happens
via the `+CNMI=*,*,2,*,*` whens setting up unsolicted events in
`modem_messaging_enable_unsolicited_events` (ETSI TS 127 005).
This adds support for the Cell Broadcast interface allowing to
receive, list, read and delete Cell Broadcast messages via the
org.freedesktop.ModemManager1.Modem.CellBroadcast and
org.freedesktop.ModemManager1.Cbm interfaces.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
This allows to parse the CBMs parameters like channel, part number and
message text. We parse uncompressed GSM7 and UCS2 encodings as
described in 3GPP TS 23.038.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
When setting an operator, AT+COPS overwrites the currently set allowed mode. Equally, the other way around, when setting the current mode, the configured operator is overwritten.
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
==3851== Conditional jump or move depends on uninitialised value(s)
==3851== at 0x23CF65: network_reject_indication_cb (mm-broadband-modem-qmi.c:5434)
==3851== by 0x4D00865: g_cclosure_marshal_VOID__BOXEDv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7200.4)
==3851== by 0x4D196FF: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7200.4)
==3851== by 0x4D19862: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7200.4)
==3851== by 0x4F7C250: process_indication (qmi-nas.c:70290)
==3851== by 0x4DFA6C4: __qmi_client_process_indication (qmi-client.c:172)
==3851== by 0x4DFEE2D: process_indication_idle (qmi-device.c:1697)
==3851== by 0x4A26C43: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
==3851== by 0x4A7C2B7: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
==3851== by 0x4A262B2: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
==3851== by 0x178042: main (main.c:236)
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/931
Referenced commit broke custom init flows because the AT port
was not opened when custom inits were run, which was the case
before the commit landed.
Rework probing flow to follow a step model like much of our
other code, and ensure that the AT port is opened as part
of the custom init flow.
Fixes: 7937a89a37 port-probe: rework and consolidate port probe flow for AT/QCDM/QMI/MBIM
Signed-off-by: Dan Williams <dan@ioncontrol.co>
FM350 modems report an invalid rssi threshold (always 0) in the signal-state response message.
It results in signal quality not being updated. We can use this patch to workaround this bug.
The NL668-EAU 4G, 3G, 2G CAT4 is a modem from fibocom and is using a diffrent
USB_VID for this modem. By adding the new USB_VID, the 'fibocom' plugin is
now responsible and not the 'generic' plugin.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Some modems like the Qualcomm-based Cellient MPL200 and SimTech
SIM7100E will crash some time after requesting operator reserved PCO.
The new udev tag ID_MM_QMI_PCO_DISABLED disables the PCO settings
request when set, indirectly disabling PCO.
Signed-off-by: Stig M. Baugstø <1129097-stigma@users.noreply.gitlab.freedesktop.org>
The vid:pid information of a given device is useful information,
especially when analyzing user provided logs.
This change makes the vid:pid information be included at msg level in
the same message that reports the plugin in use. It also removes some
redundant messages.
Certain QMI-based USB modems will report an "unknown" power state upon
boot, before our first attempt to set one:
$ sudo qmicli --dms-get-operating-mode -d /dev/cdc-wdm0 -p
[/dev/cdc-wdm0] Operating mode retrieved:
Mode: 'unknown'
HW restricted: 'no'
Due to this, the logic trying to recover the previous power state
during an attach settings update would end up asserting:
[modem3] set initial EPS bearer settings state (3/5): recover previous power state
**
ERROR:../src/mm-iface-modem.c:4554:mm_iface_modem_set_power_state:
code should not be reached
Bail out! ERROR:../src/mm-iface-modem.c:4554:mm_iface_modem_set_power_state:
code should not be reached
Aborted
This is a rare case, and instead of handling it in the QMI specific
implementation, we can try to fix it in a safer way directly in the
logic that handles the attach settings update. If we ever detect that
the reported power state is "unknown", we will default it to "on"
while emitting a warning.
If the DeviceContext is cancelled, we remove it from the list of
tracked DeviceContexts in the MMPluginManager, so that new port
additions happening at the same time don't end up being added to
it.
This should allow an early cancellation of the DeviceContext without
asserting on g_assert (!device_context->extra_probing_time_id) as
there is no chance that a new port addition has reseted the extra
probing time timeout.
0x00007c1154f16abf (libc.so.6 - pthread_kill.c: 44) __pthread_kill_implementation
0x00007c1154ecbf0c (libc.so.6 - raise.c: 26) raise
0x00007c1154eb74aa (libc.so.6 - abort.c: 79) abort
0x00007c11556c08a9 (libglib-2.0.so.0 - gtestutils.c: 3450) g_assertion_message
0x00007c11556c091d (libglib-2.0.so.0 - gtestutils.c: 3476) g_assertion_message_expr
0x00005897d1ed6e7b (ModemManager - mm-plugin-manager.c: 805) device_context_unref
0x00005897d1ed6ab9 (ModemManager - mm-plugin-manager.c: 163) common_async_context_free
0x00005897d1ed5dd6 (ModemManager - mm-plugin-manager.c: 1136) port_context_run_ready
0x00007c1155550e86 (libgio-2.0.so.0 - gtask.c: 1309) g_task_return_now
0x00007c115554fe50 (libgio-2.0.so.0 - gtask.c: 1378) g_task_return
0x00007c115555047b (libgio-2.0.so.0 - gtask.c: 2022) g_task_return_new_error
0x00005897d1ed581a (ModemManager - mm-plugin-manager.c: 296) port_context_complete
0x00005897d1ed6259 (ModemManager - mm-plugin-manager.c) plugin_supports_port_ready
0x00007c1155550e86 (libgio-2.0.so.0 - gtask.c: 1309) g_task_return_now
0x00007c1155550eb9 (libgio-2.0.so.0 - gtask.c: 1323) complete_in_idle_cb
0x00007c115569c91b (libglib-2.0.so.0 - gmain.c: 3460) g_main_dispatch
0x00007c115569c91b (libglib-2.0.so.0 - gmain.c: 4200) g_main_context_dispatch
0x00007c115569cc37 (libglib-2.0.so.0 - gmain.c: 4276) g_main_context_iterate
0x00007c115569ceb5 (libglib-2.0.so.0 - gmain.c: 4479) g_main_loop_run
0x00005897d1e715bf (ModemManager - main.c: 236) main
0x00007c1154eb7705 (libc.so.6 - libc_start_call_main.h: 58) __libc_start_call_main
0x00007c1154eb77c1 (libc.so.6 - libc-start.c: 360) __libc_start_main_impl
0x00005897d1e70f10 (ModemManager + 0x000b3f10) _start
0x00007ffd5acc5057
Manually reproducing this issue was challenging, so adding here the
steps taken, for reference. This is with ModemManager running with
--no-udev (i.e. port additions reported via mmcli). The key to
reproduce the problem is the different timing between the port
additions and removals of the three ttyACM ports.
COUNT=1
while ((COUNT < 10000)); do
echo "$COUNT..."
COUNT=$((COUNT + 1))
(
sudo mmcli --report-kernel-event="name=ttyACM0,subsystem=tty,action=add"
TIMEOUT="0.0$(((RANDOM % 10) + 1))"
sleep $TIMEOUT
sudo mmcli --report-kernel-event="name=ttyACM0,subsystem=tty,action=remove"
) &
(
sudo mmcli --report-kernel-event="name=ttyACM1,subsystem=tty,action=add"
TIMEOUT="0.0$(((RANDOM % 10) + 1))"
sleep $TIMEOUT
sudo mmcli --report-kernel-event="name=ttyACM1,subsystem=tty,action=remove"
) &
(
sudo mmcli --report-kernel-event="name=ttyACM2,subsystem=tty,action=add"
TIMEOUT="0.0$(((RANDOM % 10) + 1))"
sleep $TIMEOUT
sudo mmcli --report-kernel-event="name=ttyACM2,subsystem=tty,action=remove"
) &
TIMEOUT="0.0$(((RANDOM % 10) + 1))"
sleep $TIMEOUT
COUNT=$((COUNT + 1))
done
Dan Williams
Lukas Voegl
Rafael Fontenelle
Dan Williams
Aleksander Morgado
Aleksander Morgado
Michal Mazur
Mank Wang
Guido Günther
Lorenzo Zolfanelli
Bolan Wang
Aleksander Morgado
Daniele Palmas
Florian Eckert
Stig M. Baugstø