If we find that none of the requested auth settings are supported, we
should fail and return an error.
Also, make sure we set the CHAP fallback default only if either user
or password are given.
Unlike other implementations, with MBIM we cannot tell the modem to
connect a given profile by its profile number, which is a bit strange,
but it looks like there is no way to do that. So, if the user requests
to connect a given profile, what we do is load the profile settings by
querying the modem, and use those settings in the connect request.
We use the "Provisioned Contexts" message support to add and edit
profiles.
We also use the same message, with context-type set to "none" to
attempt deleting it, although that doesn't seem to be fully supported
by all modems. E.g. the EM7345 (FIH7160_V1.1_MODEM_01.1349.12) will
still report contexts 'deleted' in this way, with the context-type set
to "none".º
There is no longer need to perform all the CID selection logic in the
broadband bearer connection procedure, we can rely on the new profile
management operations to do the same thing.
We can do this because we're sure that all the MMBroadbandModem
objects implement the MMModem3gppProfileManager interface.
Additionally, given that we now provide the profile ID value as part
of the MMBearerConnectResult, we no longer need a custom
mm_broadband_bearer_get_3gpp_cid() as we can use the generic
mm_base_bearer_get_profile_id() for the same purpose.
Using AT+CGDCONT for profile settings management (querying, updating,
reseting), AT+CGDEL for profile deletion, and AT+CGACT for activation
status management (check, deactivate).
This interface will provide support for the profile management
operations in different modem types.
This initial commit introduces support for the interface and provides
handlers for the methods that may be called in the interface.
The new helpers allow converting a PDP context list returned from the
+CGDCONT? parser to a list of 3GPP profile objects.
The new mm_3gpp_profile_list_find_best() method is equivalent to the
mm_3gpp_select_best_cid() one, but using profile objects as
input/output instead of specific settings.
The unit tests that were testing mm_3gpp_select_best_cid() are also
converted to use mm_3gpp_profile_list_find_best().
Some of the operations performed by the profile management interface
will require checking whether the operation is attempted on a profile
for which there is a known connected bearer object.
We introduce a new method to lookup a bearer in the bearer list by its
connected profile id.
Implementations that support profile management will provide the
connected profile id value in the MMBearerConnectResult returned to
the base bearer object during the connection attempt.
We define a new 'profile-id' setting in the bearer properties that
users will use to specify which connection profile of the ones
available in the device should be connected.
When the 'profile-id' is given, the associated bearer object will be
bound to the 'profile-id', and the user is able to provide additional
settings to apply on top (e.g. if the profile storage doesn't allow
some of the settings we support, like 'apn-type', or if the setting is
completely unrelated to profiles, like 'multiplex').
After introducing the 'profile-id' as a valid setting in the bearer
properties, we also reimplement the properties object internals to
make use a 3GPP profile for the subset of common settings between both
objects.
This new setting allows the user setting up the connection to specify
the purpose of the connection being brought up.
Until now, we would always assume that connections are exclusively
brought up for connecting to the Internet, also limited by the
inability to connect to multiple different APNs at the same time.
But that may really not be true as there may be additional services
that may be accessed through other APNs, like MMS services or even
private networks for companies that have their own APNs on a given
operator (e.g. not that uncommon with banks and connected cars).
The new APN type setting will not change the way the bearer is
connected, but will allow the connection manager to decide what kind
of networking setup the specific connection needs.
This new setting can be provided by the user itself, or implicitly
read from the device if the device stores this information.
The "ready" methods for each step in the state machine must be ordered
from bottom to top, so that the readers can read the methods in that
order when following the logic.
In addition to differentiating between IPv4 and IPv6 clients, we also
need to explicitly allocate different clients in different bearer
objects when in multiplexing.
Connecting the second family of a dual stack connections fails with
'PolicyMismatch' when muxing is setup after family selection.
Switching the order of the family selection and muxing setup to
fix the problem. Looks like family selection must be the very last
WDS request before connecting the client.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Fix typo causing crash when WITH_QRTR is undefined:
[6596]: <debug> [1619029470.854688] [cdc-wdm0/probe] probing QMI...
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x77a7310f in install_property_internal () from /usr/lib/libgobject-2.0.so.0
(gdb) bt
#0 0x77a7310f in install_property_internal () from /usr/lib/libgobject-2.0.so.0
#1 0x77a731db in validate_and_install_class_property () from /usr/lib/libgobject-2.0.so.0
Backtrace stopped: frame did not save the PC
Fixes: ec375bd959 ("port-qmi: add support for QRTR")
Signed-off-by: Bjørn Mork <bjorn@mork.no>
SDX55 modem can take slighlty more than 25 seconds to start all
its services from cold boot/reset (including QMI services), causing
QMI port opening timeout error. This patch increases the qmi_device_open
timeout from 25 seconds to 45 seconds to prevent such issue.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
If multiplexing is not supported by the network driver, do not enable
it by default and fail in case it is required.
This is the case for mhi_net driver, that do no implement multi MBIM
session (only session 0 is supported).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Add support for the Linux wwan subsystem that started to expose
control channel as character devices (e.g. /dev/wwan0p1MBIM...).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
The new Linux WWAN subsystem exposes the various WWAN control ports
as character devices. WWAN port device naming follows the following
convention: wwanXpYP, where X is the wwan device index, Y the port
index and P the port type/protocol.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Increase the timeout from 10 seconds to 30 seconds when reading the
operator information through the MBIM_CID_HOME_PROVIDER query.
We have observed cases where it took more than 12 seconds on a Fibocom
L850-GL modem with specific China Unicom SIMs.
This timeout was actually the cause of a corruption of the operator name
(e.g. returning '@' rather than the real operator name) on the Intel
XMM7360 based L850-GL. The following scenario was happening:
- the base-sim code sends a first MBIM 'home-provider' query to read the
operator identifier.
- this query times-out after 10 seconds.
- the base-sim immediately sends another MBIM 'home-provider' query to
read the operator name.
- the modem returns a corrupted operator identifier.
Intel helped for the debugging and indicates that when the first query
happens, the modem starts reading the SIM files (EF SPN/PNN), apparently
it's taking a long time, when it's receives the second query while the
first one is not entirely processed, this triggers a bug (in the modem
firmware) and returns a corrupted name.
The QmiDeviceExpectedDataFormat is specific to modules exposed by the
qmi_wwan driver, it has nothing to do with other drivers we may find
in the system like bam-dmux or ipa, which don't allow changing the
expected data format.
The port setup logic is now updated to use a new flags bitmask that
specifies which kernel data modes are supported or currently
available.
Add a common physdev UID to all ports in the Qualcomm SoC, so that they
are all bound together to the same modem object.
This change assumes that no external plugged device ever exports a
QRTR node in the QRTR bus (e.g. that no PCI or USB device would ever
do that). This assumption is likely wrong, but given that we're
currently limiting the QRTR support to the Qualcomm SoC plugin, the
assumption is valid for us for now.
The WITH_QRTR symbol in config.h will let us know both if libqrtr-glib
is found and if libqmi-glib is compiled with QRTR support (as per the
exposed "qmi_qrtr_supported" variable in pkg-config).
No change in the logic, just in how it's setup. E.g. we will load the
max number of retries just once when the logic starts, instead of
checking it on every iteration.
Also some other minor coding style changes included, e.g. adding the
timeout between retries as a defined symbol.
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.
