If a SIM is known to exist, for e.g. if it was created during load_sim_slots,
persist a few more times before giving up on the SIM to be ready. There
are modems on which the SIM takes more than 15s to be ready, luckily,
they happen to be QMI modems where the SIM's iccid in load_sim_slots
lets us know that there is a sim.
ModemManager[6954]: <warn> [1618260091.319919] [br0] invalid sysfs path read for net/br0
**
ERROR:kerneldevice/mm-kernel-device-generic.c:235:ptr_array_add_sysfs_attribute_link_basename: assertion failed: (array && sysfs_path && attribute)
Bail out! ERROR:kerneldevice/mm-kernel-device-generic.c:235:ptr_array_add_sysfs_attribute_link_basename: assertion failed: (array && sysfs_path && attribute)
Thread 1 "ModemManager" received signal SIGABRT, Aborted.
(gdb) bt
#0 0x00007ffff7438ef5 in raise () at /usr/lib/libc.so.6
#1 0x00007ffff7422862 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff76c2084 in () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff771d85d in g_assertion_message_expr () at /usr/lib/libglib-2.0.so.0
#4 0x00005555556a5337 in ptr_array_add_sysfs_attribute_link_basename (array=0x5555557de520, sysfs_path=0x0, attribute=0x555555703bd8 "driver", out_value=0x0)
at kerneldevice/mm-kernel-device-generic.c:235
#5 0x00005555556a542b in preload_contents_other (self=0x5555557a6c60) at kerneldevice/mm-kernel-device-generic.c:255
#6 0x00005555556a6485 in preload_contents (self=0x5555557a6c60) at kerneldevice/mm-kernel-device-generic.c:517
#7 0x00005555556a7fb6 in check_preload (self=0x5555557a6c60) at kerneldevice/mm-kernel-device-generic.c:980
#8 0x00005555556a855f in initable_init (initable=0x5555557a6c60, cancellable=0x0, error=0x7fffffffe5c8) at kerneldevice/mm-kernel-device-generic.c:1127
#9 0x00007ffff78a2f41 in g_initable_new_valist () at /usr/lib/libgio-2.0.so.0
#10 0x00007ffff78a2ffa in g_initable_new () at /usr/lib/libgio-2.0.so.0
#11 0x00005555556a8205 in mm_kernel_device_generic_new_with_rules (props=0x5555557a5fa0, rules=0x7fffec001e30, error=0x7fffffffe5c8) at kerneldevice/mm-kernel-device-generic.c:1042
#12 0x00005555556a827d in mm_kernel_device_generic_new (props=0x5555557a5fa0, error=0x7fffffffe5c8) at kerneldevice/mm-kernel-device-generic.c:1063
#13 0x00005555555aba9c in handle_kernel_event (self=0x555555793220, properties=0x5555557a5fa0, error=0x7fffffffe5c8) at mm-base-manager.c:414
MM used to iterate over each SIM slot to load IMSI, operator name etc.
However, switching slots at start up caused a few issues in the real
world.
a) Sierra Wireless' AUTO-SIM feature, the hidden SIM slot switching
is actually triggering a full modem reset (because the firmware
detects a new SIM for a different operator, and automatically resets
itself to load the firmware+carrier config associated to that other
operator).
b) The IMSI on slot 2 is reported to be the same as slot 1.
This is solved by adding a 1000ms delay before reading IMSI
on slot 2, after GET_CARD_STATUS indicates the sim is ready. The
delay means a 2s startup penalty when both slots are loaded.
c) 2/5 developers have encountered a fw bug where the modem
incorrectly reports that the SIM on slot 1 has vanished
after the sequence of slot switches. This makes the modem
unusable.
d) If the eSIM daemon changes slots and opens a channel to the eUICC,
MM will detect a hotswap, and break the channel during reprobe.
e) SIMs from a certain large operator in the US take over 20s to be
ready. Thus, switching to such a SIM for just loading IMSI may not be
worth it.
This change does not affect detection of sims in all slots. We still
expose the iccid and presence of all sims. However, properties like
IMSI and operator_name will not be exposed for the inactive slot.
==226546== Invalid read of size 4
==226546== at 0x5068CB7: g_error_matches (in /usr/lib/libglib-2.0.so.0.6600.7)
==226546== by 0x1BAC86: load_network_timezone_ready (mm-iface-modem-time.c:218)
==226546== by 0x4EA827E: g_simple_async_result_complete (in /usr/lib/libgio-2.0.so.0.6600.7)
==226546== by 0x17AE2C: at_command_ready (mm-base-modem-at.c:538)
==226546== by 0x4EA827E: g_simple_async_result_complete (in /usr/lib/libgio-2.0.so.0.6600.7)
==226546== by 0x24B475: serial_command_ready (mm-port-serial-at.c:378)
==226546== by 0x4EA827E: g_simple_async_result_complete (in /usr/lib/libgio-2.0.so.0.6600.7)
==226546== by 0x244F94: command_context_complete_and_free (mm-port-serial.c:141)
==226546== by 0x246861: port_serial_got_response (mm-port-serial.c:755)
==226546== by 0x246923: port_serial_timed_out (mm-port-serial.c:785)
==226546== by 0x50863C3: ??? (in /usr/lib/libglib-2.0.so.0.6600.7)
==226546== by 0x5085B83: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.6600.7)
There is no point in providing a configurable default IP family in the
bearer object, because we can always assume IPv4 as being the only
default expected.
Simplify the logic and also provide a new method to get the normalize
the IP family, using IPv4 as default always.
The GLists maintained in the logic need to be explicitly freed (just
the lists, not the list contents) if we exit early on error or if we
end up deciding that the specific ports are available but unsupported
by the plugin (e.g. if a plugin that doesn't support net ports finds
net ports in the modem).
==225333== 24 bytes in 1 blocks are definitely lost in loss record 2,024 of 5,525
==225333== at 0x483E77F: malloc (vg_replace_malloc.c:307)
==225333== by 0x506C539: g_malloc (in /usr/lib/libglib-2.0.so.0.6600.7)
==225333== by 0x508DC8F: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6600.7)
==225333== by 0x50636B4: g_list_append (in /usr/lib/libglib-2.0.so.0.6600.7)
==225333== by 0x17E671: mm_base_modem_organize_ports (mm-base-modem.c:1298)
==225333== by 0x1E4409: mm_plugin_create_modem (mm-plugin.c:1094)
==225333== by 0x162C81: mm_device_create_modem (mm-device.c:481)
==225333== by 0x15DE60: device_support_check_ready (mm-base-manager.c:218)
==225333== by 0x4EA8173: ??? (in /usr/lib/libgio-2.0.so.0.6600.7)
==225333== by 0x4EAC6E8: ??? (in /usr/lib/libgio-2.0.so.0.6600.7)
==225333== by 0x16730F: device_context_run_ready (mm-plugin-manager.c:1533)
==225333== by 0x4EA8173: ??? (in /usr/lib/libgio-2.0.so.0.6600.7)
If using PPP, ModemManager is never in charge of deciding when the
connection is finished, because that would end up making ModemManager
try to use the TTY port while pppd is still using it.
When the modem goes unregistered for some time, we should not force
the disconnection of the bearer object, we still need to wait for pppd
to tell us the modem is disconnected.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/331
The original logic in the MBIM modem would assume that if we had more
than one network interface in the same modem, we could connect
multiple data interfaces, each one with a different session. That
logic is actually wrong, when using the master (non-multiplexed)
network interface we should always use session id 0, which is the one
holding all non-VLAN-tagged traffic.
So, remove the logic that automatically creates new bearers with a
different session id, as that is really wrong.
Also, keep track of the MMPortMbim instead of the MbimDevice directly,
because the new multiplex support will require operations on the port
as well, not only on the device.
We want to start with the data ports as clean as possible when the
modem is initialized, so we make sure the master interface is down and
that all links found are removed. This ensures a clean restart if
e.g. the daemon crashes for some other reason.
This allows us to know which of the subsystem or name for a
removed device is triggering the assertion from just a stack
trace that contains line information.
The acquisition order preference TLV must always have the same number
of elements, just the order of the elements should be different.
Also, always prefer the acquisition order preference TLV to the
GSM+WCDMA specific one, which is the same logic the modem applies.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/340
Loading capabilities is the very first step of the state machines, and
so we can rely on the "NAS Get SSP" method performed there to process
all feature checks of the SSP response.
Until now we were only considering TP/SSP unsupported if we received
a QMI protocol error (e.g. reporting unknown command).
We now also consider TP/SSP unsupported if the actual request
succeeds, but an error is reported in the response. There is no point
in considering TP/SSP supported if the plain get request without input
TLVs given fails.
Retrieve operator name from plmn_name based on current operator id.
If service name is available, use service name as operator name.
If not, use the long or short name.
Before invoking AT+CPOL? for loading preferred networks list from
SIM, AT+CPOL=,2 is executed to make sure that the returned
operator codes are in expected (numeric) format.
The reset_bearer_connection() method is called during dispose, and if
a link had been created during the connection attempt, we would be
increasing the reference to the bearer object during dispose(), which
should never happen.
Just avoid passing any callback to the cleanup_link() method, as we
really were using that only for logging purposes.
In BAM-DMUX based setups we already have multiple network interfaces
exposed in the system, which we bind to using the SIO port number.
So, disable QMAP multiplexing in this case, to simplify the setup and
avoid attempting to create additional net links when connecting
multiple bearers.
The MMPortQmi may need to know very early what kind of net ports are
going to be used later on during connection, e.g. to decide what kind
of multiplexing capabilities are available and such.
So, once we have organized ports in the modem, we'll take the driver
of the first network port in the list of data ports, and pass it down
to all QMI ports setup in the modem object.
For the qmi_wwan driver, we have imposed a limitation of max 4 links
when using the add_mux/del_mux interface, because we're forced to
precreate links before multiplexing may be enabled.
When using rmnet over qmi_wwan, or rmnet over other drivers, we don't
have any limitation other than the one imposed by the WDA protocol
itself. The amount of links that may be created in this case is
1 + (QMI_DEVICE_MUX_ID_MAX - QMI_DEVICE_MUX_ID_MIN).
This information is loaded in the MMPortQmi, used to create the
MMBearerList in the QMI modem, and finally populated in the
'MaxActiveMultiplexedBearers' property of the modem interface.
The user of the ModemManager API will bring up the data network
interface exposed in the Bearer IP settings (i.e. the link interface
when using multiplexing). But for instantiated network links, we also
need to have the master interface brought up before any traffic can go
through the link interface.
We don't check whether the master interface is already up before
attempting to bring it up, we just attempt to bring it up.
If the user requests or requires to use multiplexing support, try to
create a data port link and bind the WDS client(s) to it.
If the multiplex is requested but not required, we allow link creation
failures or setups where multiplexing isn't supported; we just go on
with the default connection setup without multiplexing, as long as
there is no bearer connected on the same data network interface.
If the multiplex is required and for any reason it cannot be fully
setup, we will fail the connection attempt right away.
The data port link is created in the system via the QmiDevice in the
open MMPortQmi, but it MUST be notified by the kernel (e.g. via udev
or via kernel events) before the connection attempt goes on.
Pavan Holla
Aleksander Morgado
Andrew Lassalle
Eric Caruso
Madhav
Teijo Kinnunen