| Age | Commit message (Collapse) | Author |
|---|
|
During the enabling phase, the modem may receive a lot of asynchronous
updates reporting registration info changes, but we were fully
ignoring them because the modem was not yet enabled. The problem with
this is that as soon as we reach the enabled state, we may not receive
additional info, so we would be left in 'enabled' state until new
asynchronous updates are received or until we start a connection
attempt.
We can solve this by triggering an explicit update with the
registration information that we have cached as soon as we're enabled.
|
|
|
|
|
|
Only if transitioning into a "registered" state ("home", "roaming",
"partner") or if "denied"; otherwise, assume LAC/TAC/CID are all
unknown.
This change makes the logic also reload the location info on
registration updates reported asynchronously via notifications.
|
|
The profile management APIs implemented by Microsoft in the MBIM
extensions provide certain features that are not available via other
means (e.g. ip type, access type preference, roaming allowance...).
Unfortunately, these APIs require the current list of profiles
installed in the modem to be a bit special; e.g. with one profile max
for each context/APN type. If this does not happen, the operations
will fail, or they will update contexts that should not be updated.
So, we disable for now the MBIM extension profile management support;
the logic is there, but not used by default.
|
|
In order to show the properties of the profile management interface, e.g.:
$ sudo mmcli -m a --3gpp-profile-manager-status
-----------------------------------
3GPP profile manager | index field: apn-type
|
|
Instead of expecting a specific profile id, allow the command to
support different index field types.
|
|
The modem may report the 'apn-type' field is the one to be used as
index; if that's the case, allow setting and deleting profiles based
on the given 'apn-type' field.
This change also makes the internal profile management operations use
one index field or another, based on what the protocol implements.
|
|
|
|
|
|
For most protocols, the operations to manage profiles require a unique
'profile-id' as index. This applies to AT, QMI and generic MBIM.
But for MBIM using the Microsoft Extensions for profile management,
this is no longer true; the device expects the 'apn-type' to be the
index.
This new property lets the user know which is the expected index field
in the Delete() and Set() operations.
|
|
MbimProvisionedContextElementV2
Microsoft defined a new extended version of the "provisioned contexts"
operation from the generic MBIM basic connect service. This extended
version adds several new settings that can be stored in the profile
(e.g. IP type, media type, roaming allowance...).
But this new version has a huge drawback; we cannot specify single
profiles via their unique id while we perform update/delete operations
in the modem. Instead, Microsoft explains that we should use the
context type to identify the target context; but this will ONLY work
if we have one context defined for each type. As soon as we have
multiple contexts of the same type, this operation may fail or
otherwise update multiple contexts at once.
|
|
At least not yet.
|
|
At least not yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not applicable to bearer properties, as this is exclusively a proflie
management setting, unrelated to connection attempts.
|
|
|
|
Not applicable to bearer properties, as this is exclusively a proflie
management setting, unrelated to connection attempts.
|
|
|
|
Sometimes it's useful to know how a given stored profile was created,
so devices can store and report this kind of information.
|
|
The 'allow-roaming' setting should be considered deprecated for 3GPP
devices that support the new 'roaming-allowance' setting, which is
much more detailed (as it allows to differentiate between partner and
non-partner networks) and may also be stored as part of a profile.
|
|
This is never part of profile settings, it's a volatile configuration
applicable to the connection attempt ongoing with the given bearer
settings.
|
|
This setting is stored as part of the profile in the device, and
allows the user to specify that a given profile must not be used in
any way by the modem (if set to 'FALSE').
|
|
In 5G capable devices, which can support multiple types of access
types (either 3GPP or non-3GPP), the UE may request to use a 3GPP
access type exclusively, prefer a 3GPP access type, or just report no
preference.
When supported, this field may also be part of the settings that can
be stored as part of a profile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A new set of property+method is added to be able to configure the 5G
specific registration settings, initially defining the support for the
MICO mode.
The property name starts with "Nr5g" instead of "5gNr" because of the
limitations imposed by the GObject type system on how properties with
numbers can be named.
|
|
`i18n.merge_file` has been ignoring positional arguments for a time and explicitly rejects with error since meson 0.60.0.
|
|
The udev flag "ID_MM_QMI_FACILITY_LOCK_QUERY_REDUCED" allows to skip
facility lock state query "get_ck_status" on the DMS path for devices
where this isn't implemented properly.
On devices that have enabled "device locks", this flag won't work well.
Skipping the query doesn't disable the locks.
Fixes #448
|
|
Main thing that's required to get modem hot-swapping to work is the
UDCONF=50,1 command(see u-blox AT-command manual). But there are a lot
of u-blox modules which do not support this command. So in this patch,
it's supposed that this thing is configured beforehand(Like the UUSBCONF
functioning mode) for modules, where SIM hot-swaping feature is
possible. For the modems where it's not, the patch will not have any effects.
----
For ublox modems, CIEV: 12(X) messages allow to know if
SIM is (un)plugged. The values are encoded as:
- 0: no SIM detected
- 1: SIM detected
It's required from a modem to generate these events about the SIM
detection state.
To set up these `CIEV: 12,(X)` URC events the `+CMER=1,0,0,1,0` command
is used. That command is supported by almost all u-blox modems except
SARA-G300/SARA-G310/LEON-G1(For these models the hot-swap feature will
not work).
As this 12 that is used in CIEV may be completely different in other
modules, the test command parsing is quite important to get that index
number. So, this logic is also added in cind_simind_format_check_ready
function.
----
It seems that it's necessary to issue this `+CMER` set up there despite
that the `+CMER` configuration will take place later in the 3GPP
interface enabling sequence. Because without it simind indications
will not be enabled at all.
CMER configuration may be later overwritten by 3GPP interface enabling
sequence, but in the worst-case scenario only hot-swap feature will not
work.
|
|
If we have a modem with an established connection, and then the
SIM is getting removed from that modem, this forces modem reprobing
sequence.
It looks like that:
```
mm-base-modem:mm_base_modem_process_sim_event
-> mm-base-modem:mm_base_modem_disable
-> mm-base-modem:disable
-> mm-broadband-modem:common_disable
-> mm-broadband-modem:disabling_step,
-> ctx->step=DISABLING_STEP_FIRST
-> ctx->step=DISABLING_STEP_WAIT_FOR_FINAL_STATE
-> ctx->step=DISABLING_STEP_DISCONNECT_BEARERS
```
At this stage, there is no actual connection existing already, but
bearer objects still exist and are still marked as connected.
So, if there were any active bearers - they will be disconnected.
In order to disconnect, ublox bearer sends +CGACT=0,%u, modem then
will return CME ERROR: 10(SIM not inserted):
```
[modem0/ttyACM0/at] --> 'AT+CGACT=0,1<CR>'
[modem0/ttyACM0/at] <-- '<CR><LF>+CME ERROR: 10<CR><LF>'
[modem0/ttyACM0/at] operation failure: 10 (SIM not inserted)
[modem0/bearer0] couldn't disconnect: SIM not inserted
```
this error will break disabling and reprobing. To fix that, it's
require to add 'SIM not inserted' state as a valid condition to
continue bearer disconnection.
|
|
'Connected'
By the time we report the bearer as 'Connected', the DBus client
should also be able to know right away the value of
'ReloadStatsSupported', instead of needing to wait for it to be
updated asynchronously.
This logic adds one additional step in the generic connection
sequence for this purpose, which is run after the modem is connected
but before we report the state change via DBus.
|
|
This property means that the current bearer can reload stats and read TX
and RX bytes transmitted.
The property is initiliazed as soon as the bearer is connected.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
|
|
|
|
We originally did only 3 attempts every 3s, so the maximum probing
time for a given TTY port looking for AT capabilities was 9 seconds.
We now duplicate the amount of times, so up to 18s of port probing,
which is quite a lot more than before, but unfortunately it's needed
because most new modems take a lot of time to boot up internally.
The way to avoid this long probing time is to make sure port type
hints for the possible AT ports are set correctly.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/379
|
