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
The power up and down operations are already synchronized at
interface level, so there is already a guarantee that they won't
happen at the same time.
For the reset and power off operations, it is assumed that the modem
will either reset or power off, so there should be no need to sync
those operations with others, as the modem object will eventually go
away altogether in both cases.
If a request to lock the operation with the override type arrives, all
pending operations will be immediately cancelled, and no new lock
requests will be allowed.
Follow up changes will introduce support to run exclusive enable and
disable operations, effectively ensuring that only one enabling or
disabling task is processed at any given time, so the support for
completing parallel operations with the same result is no longer
needed.
That logic was anyway flawed, as it did not consider complex cases
like a disable request received between two enable requests, the order
of incoming requests was not maintained.
The main reason for adding the parallel enable/disable operation logic
was for the case where 2 separate users tried to enable the modem at
the same time. In that case, we did not want to run 2 separate
enabling operations from scratch, and completing one would complete
the second one as well. With the new operation lock logic, the same
result is achieved, as the 2nd enabling operation would find the modem
already enabled, if the 1st one succeeded.
This removal is done before introducing the new exclusive operation
support in the enable/disable path in order to make it easier and more
consistent with other operations that will also be included in the
synchronization.
There are certain operations that cannot be run in parallel, e.g. one
should not disable and bring the modem to low power mode while there
are also incoming requests to enable the modem. This type of errors
will typically happen when multiple DBus clients are trying to use the
same modem at the same time for different purposes.
We do not have any way to have DBus clients take exclusive ownership
of a given modem object, so the best we can do for now is trying to
synchronize operations that cannot be run together, preserving the
order in which they arrived, and running them one by one.
The modem state property update was happening at disabling task context
free time, after the actual task completion has happened.
Avoid wrong assumptions on the modem state value in operations
scheduled after the task completion, in the same way as done in the
enabling sequence.
The L850 seems to report 0xFFFFFFFF as MbimContextIpType value, which
is not a correct value.
Instead of printing "(none)" (the default used by glib when trying to
print a NULL pointer as a string), make it so that we end up printing
the actual numeric value in hex.
<dbg> [modem0] 'home' settings found at configuration index 0
<dbg> [modem0] 'non-partner' settings found at configuration index 1
<dbg> [modem0] 'partner' settings not found
<dbg> [modem0] updates in the home LTE attach configuration settings:
<dbg> [modem0] ip type: 'unknown (0xffffffff)' -> ''ipv4v6'
<dbg> [modem0] updates in the partner LTE attach configuration settings:
<dbg> [modem0] none (skipped)
<dbg> [modem0] updates in the non-partner LTE attach configuration settings:
<dbg> [modem0] none
Instead of updating the attach settings associated with the home
network, update all three to the same values, so that network attach
while roaming uses the same settings as in home.
This is a major change in behavior; if there is ever a need to roll
back to the old behavior because a given device doesn't support this,
we can provided device-specific behaviors using the
load_set_initial_eps_bearer_settings_mask() virtual method.
L850 modems running a firmware version less than 18500.5001.0.7 and
using AT&T SIM cards with MCCMNC 310280 do not support specifying
"partner" settings in the MBIM operation to set the LTE attach
configuration.
The ModemManager API provides a single method to update the attach
settings used in LTE registration, but in the MBIM protocol there are
three different distinct configurations associated with that
operation.
Until now we have exclusively updated the "home" settings, leaving the
"partner" and "non-partner" settings untouched (i.e. we loaded the
existing settings for these sections, and used the same ones when
providing our update operation).
Unfortunately, this logic does not fit all needs. Some modems will
require all 3 elements to be unconditionally updated, and some other
modems may need to fully skip one of the configuration sections.
The rework done in this commit does not change the behavior, but
provides the ability for subclasses to modify how the operation is
done, via a set of flags that is provided on each update attempt (as
sometimes the behavior is operator-specific).
We look for the home settings, but also allow to optionally lookup for
the partner and non-partner settings, logging in each case if we find
anomalies (e.g. if not found or if found duplicated entries).
The device always reports empty TX/RX values so there is no point in
periodically asking.
The logic to poll for stats is kept in place only if the device
requires the IP packet filters removal hack.
The Cinterion specific implementation relies on the generic one but
adds the authentication information support using ^SGAUTH.
The loading of the initial EPS bearer status (i.e. the one agreed with
the network, not the settings) no longer has any Cinterion specific
behavior. The auth settings are NOT reported in the initial EPS bearer
status.
The implementation in the generic MMBroadbandModem object should fit
well instead of the custom implementation.
There is also no need to specify via udev tags which is the initial
EPS bearer context id, we try to automatically guess it in runtime.
The main issue here is how to select the id of the context that is
used for attach in the modem.
We will assume that the lowest cid value for the IP range returned in
the CGDCONT=? test is the one used for the attach context. This
assumption works with modems following the 3GPP specs (with cid=0) and
also in Qualcomm based modems (with cid=1).
Before the operation to update the current initial EPS bearer
settings, we will now unconditionally put the modem in low power
mode. so that when the next network registration happens we are sure
the new settings are in place.
This approach was previously applied already to all QMI-based modems
as well as to all Fibocom modems. The approach applies now to all
modems of all vendors and in all control protocols.
Let the caller of mm_iface_modem_set_power_state() know which was the
power state in the device before the actual update happened.
This is useful in cases where we want to temporarily switch to a given
power state (e.g. low) before returning to the original power state.
ptr_array_add_sysfs_attribute_link_basename() already reads the
current subsystem, so we should avoid overwriting the pointer.
==1630== 13 bytes in 2 blocks are definitely lost in loss record 270 of 3,092
==1630== at 0x4842839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1630== by 0x4A1DDE8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==1630== by 0x4A329E3: g_strdup (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==1630== by 0x26128E: ptr_array_add_sysfs_attribute_link_basename (mm-kernel-device-generic.c:244)
==1630== by 0x263FD0: preload_contents_platform (mm-kernel-device-generic.c:314)
==1630== by 0x263FD0: preload_contents (mm-kernel-device-generic.c:549)
==1630== by 0x263FD0: check_preload (mm-kernel-device-generic.c:992)
==1630== by 0x263FD0: initable_init (mm-kernel-device-generic.c:1139)
==1630== by 0x4B6DDB9: g_initable_new_valist (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==1630== by 0x4B6DE6C: g_initable_new (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==1630== by 0x262087: mm_kernel_device_generic_new_with_rules (mm-kernel-device-generic.c:1054)
==1630== by 0x17F66F: handle_kernel_event (mm-base-manager.c:689)
==1630== by 0x17F7D2: report_kernel_event_auth_ready (mm-base-manager.c:1238)
==1630== by 0x4BA37D8: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==1630== by 0x4BA3A1A: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
The logic initializing the SIM object already prints the loaded
fields, taking into account that some of them should be treated as
personal info (so redacted by default).
[modem0/sim0] loaded SIM identifier: 8988211000000123456
[modem0/sim0] loaded SIM identifier: ###
[modem0/sim0] loaded IMSI: 901700000012345
[modem0/sim0] loaded IMSI: ###
The mm_device_create_modem() was updated so that it would not run the
modem initialization implicitly. Due to this change, we must ensure
the modem initialization is run after a modem reprobe operation,
e.g. when switching SIM slots.
The logic to run the modem initialization is moved to MMDevice for
simplicity and clarity.
Fixes: 04d826f563
The whole codebase is updated to assume the MMBaseModem AT operations
require an object implementing the MMIfacePortAt interface, instead of
a MMPortSerialAt object.
In the places where we know the port is a MMPortSerialAt, e.g. when we
query explicitly for the primary or secondary serial AT port, we will
use an explicit MM_IFACE_PORT_AT() cast when calling the AT command
method.
In the places where we get_best_at_port() we're going to assume that
we don't know the port type. This method will be updated in a follow
up commit to support the MMIfacePortAt interface as well.
Aleksander Morgado