The behavior of GRegex changed in 2.73.2 once it was ported from pcre1
to pcre2. In some cases it was made more strict, which is fine, in
other cases it exposed some change in how it behaves on certain
matches that is not extremely clear whether it's ok or not.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2729
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/601
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/621
Either way, one thing that was assumed was that initializing all
GRegex/GMatchInfo variables to NULL and making sure they're NULL
before they're initialized by glib (especially the GMatchInfo) was a
good and safer approach.
So, whenever possible, g_autoptr() is used to cleanup the allocated
GMatchInfo/GRegex variables, and otherwise, g_clear_pointer() is used
to ensure that no free/unref is attempted unless the given variable is
not NULL, and also so that the variable is reseted to NULL after being
disposed.
We no longer have separate mm_base_modem_process_sim_event() and
mm_broadband_modem_sim_hot_swap_detected() methods. The only
difference between both of them was that one of them would attempt to
cleanup the ports context associated to the SIM hot swap event logic
as soon as a swap was detected, in order to avoid queueing up multiple
such events.
The previous logic wasn't working well, though, as there could be
mixed AT+QMI or AT+MBIM devices that would also require that same
cleanup and so we didn't always know which one should have been
called.
Now we have a single mm_iface_modem_process_sim_event() method, which
will trigger the reprobe and disabling, but which will also perform
the cleanup of the SIM ports swap setup as specified by the
implementation.
So, if a plugin explicitly initializes the serial ports context for
SIM hot swap handling, it should also explicitly clean it up.
Also, the initialization of the serial ports context for SIM hot swap
handling is no longer done automatically for all modems, it will be
done only for those modems using it; i.e. the modems that explicitly
report support SIM hot swap handling using AT URCs.
This property is used in the MMIfaceModem to flag whether the SIM hot
swap setup has been performed or not. The flag is now moved to the
iface-specific private context.
The property was also used in AT-based modems, so that implementations
supporting the SIM hot swap via AT URCs could flag the upper layers
whether the enabling of the feature was done correctly or not, and if
so, create and keep the AT ports context open. But this feature only
made sense in AT-based modems, i.e. an MBIM modem that detects SIM hot
swaps via MBIM indications exclusively should not require the AT ports
context open for anything. The check in the MMBroadbandModem object
has therefore been removed, and the logic will be updated so that it
only applies to AT-based modems.
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.
See log from a SARA-R410M-02B-01 before the change:
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.012330] [modem0/ttymxc4/at] --> 'AT+UBANDSEL?<CR>'
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.026831] [modem0/ttymxc4/at] <-- '<CR><LF>ERROR<CR><LF>'
Feb 01 05:40:01 unit ModemManager[304]: <debug> [1612158001.027113] [modem0/ttymxc4/at] operation failure: 100 (Unknown error)
Feb 01 05:40:01 unit ModemManager[304]: <warn> [1612158001.027298] [modem0] couldn't load current bands: Unknown error
Backed by SARA-R4 series AT commands manual, no reference to +UBANDSEL
in the manual at all.
Log after the change:
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500845] [modem0] (u-blox) support configuration found for 'SARA-R410M-02B'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500961] [modem0] (u-blox) band update requires explicit unregistration
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.501052] [modem0] (u-blox) UACT based band configuration unsupported
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.501141] [modem0] (u-blox) UBANDSEL based band configuration unsupported
Fixes: 437fb830c8 ("ublox,helpers: assume all SARA/LARA devices require COPS")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
The SARA-R410M-02B-01 only supports values 7 and 8, log excerpt:
Feb 01 05:40:00 unit ModemManager[304]: <debug> [1612158000.826046] [modem0/ttymxc4/at] --> 'AT+URAT=?<CR>'
Feb 01 05:40:00 unit ModemManager[304]: <debug> [1612158000.833596] [modem0/ttymxc4/at] <-- '<CR><LF>+URAT: (7-8),(7-8)(7-8)<CR><LF><CR><LF>OK<CR><LF>'
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.833992] [modem0] (u-blox) unexpected AcT value: 7
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.834096] [modem0] (u-blox) unexpected AcT value: 8
Feb 01 05:40:00 unit ModemManager[304]: <warn> [1612158000.834193] [modem0] couldn't load supported modes: No combinations built from +URAT=? response
The SARA-R4 series AT commands manual (and also the SARA-R5 AT commands
manual) lists them like this:
- 7: LTE Cat M1
- 8: LTE Cat NB1
After the change, log looks like this:
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.490627] [modem0/ttymxc4/at] --> 'AT+URAT?<CR>'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.499994] [modem0/ttymxc4/at] <-- '<CR><LF>+URAT: 7,8<CR><LF><CR><LF>OK<CR><LF>'
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500433] [modem0] (u-blox) current allowed modes retrieved: 4g
Feb 01 06:58:25 unit ModemManager[329]: <debug> [1612162705.500561] [modem0] (u-blox) current preferred modes retrieved: 4g
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Update the list of mobile equipment error codes according to v17.1.0
of 3GPP TS 27.007 (March 2021).
A lot of the enum values that were prefixed with the 'GPRS_' keyword
have now been flagged as deprecated, and a new enum name given to the
corresponding value.
The deprecated symbol names are kept in the compat support to avoid
breaking API/ABI.
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.
Each different plugin or protocol had a different connection attempt
value. E.g. QMI and MBIM both used 60s max for the connection attempt,
while the u-blox plugin had up to 180s for ECM based connection
setups.
This commit consolidates all plugins and protocols to use the same
timeout values for commands that may take long to respond, e.g. a
connection atempt under low signal quality conditions.
A value of 180s for the connection attempt steps and 120s for a
disconnection attempt step is considered. Note, though, that in some
cases (like a IPv4v6 setup attempt using QMI) we may have more than
one such long step, so this doesn't mean that a connection attempt
will always take less than 180s.
Users of the connection/disconnection APIs should be able to handle
the case where the attempt times out in their side (e.g. with a lower
DBus request timeout), and which would not mean the actual request
they did really failed. E.g. a connection attempt with a DBus timeout
of 30s may fail in the user with a timeout error, but the attempt
would still go on for as much as the plugin/protocol needs.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/270
In preparation for the multi-SIM setup, we need a way to tell whether
a given SIM card is active or not in the system.
On systems with one single SIM slot, the available SIM card will
always be active.
On Multi-SIM Single-Standby setups we may have multiple SIM slots with
multiple SIM cards, but only one of them will be active at any given
time.
On Multi-SIM Multi-Standby setups we may have multiple SIM slots with
multiple SIM cards that may be active at the same time. E.g. the QMI
protocol allows up to 5 different active SIM cards (primary,
secondary, tertiary...).
CHAP is almost universal nowadays, and so it is a better default
than PAP
Not changed for uBlox, that prefers an error if not specified,
and for Huawei, which uses NONE with user/pwd and has 2 CHAP choices
Instead of setting up the ID_MM_TTY_BLACKLIST tag used in 'legacy'
filter mode, tag all known u-blox GPS devices with the broader
ID_MM_DEVICE_IGNORE tag that applies under all filter modes.
Also, make this rules be installed by the plugin itself, because at
the end, it is the u-blox plugin the one attempting to probe all
devices with vid 0x1546.
We can safely cast the data in a GArray to gpointer first, and then
to the pointer type we require.
ublox/mm-modem-helpers-ublox.c: In function 'parse_bands_from_string':
ublox/mm-modem-helpers-ublox.c:1612:48: error: cast increases required alignment of target type [-Werror=cast-align]
tmpstr = mm_common_build_bands_string ((MMModemBand *)(bands->data), bands->len);
^
The incorrect ready() method was being used while disabling, which
ended up making the parent disable not being run at all.
ublox/mm-broadband-modem-ublox.c:1178:1: error: ‘voice_disable_unsolicited_events_ready’ defined but not used [-Werror=unused-function]
1178 | voice_disable_unsolicited_events_ready (MMBroadbandModemUblox *self,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ublox/mm-broadband-modem-ublox.c:458:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
458 | ctx->step++;
| ~~~~~~~~~^~
ublox/mm-broadband-modem-ublox.c:461:5: note: here
461 | case SET_CURRENT_MODES_BANDS_STEP_ACQUIRE:
| ^~~~
ublox/mm-broadband-modem-ublox.c:468:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
468 | ctx->step++;
| ~~~~~~~~~^~
ublox/mm-broadband-modem-ublox.c:471:5: note: here
471 | case SET_CURRENT_MODES_BANDS_STEP_CURRENT_POWER:
| ^~~~
...
ublox/mm-broadband-modem-ublox.c:1246:5: error: enumeration value ‘MM_CALL_STATE_UNKNOWN’ not handled in switch [-Werror=switch-enum]
1246 | switch (call_info.state) {
| ^~~~~~
ublox/mm-broadband-modem-ublox.c:1246:5: error: enumeration value ‘MM_CALL_STATE_ACTIVE’ not handled in switch [-Werror=switch-enum]
ublox/mm-broadband-modem-ublox.c:1246:5: error: enumeration value ‘MM_CALL_STATE_HELD’ not handled in switch [-Werror=switch-enum]
ublox/mm-broadband-modem-ublox.c:1246:5: error: enumeration value ‘MM_CALL_STATE_TERMINATED’ not handled in switch [-Werror=switch-enum]
If the modem requires +COPS re-registration after setting bands or
modes, use the common logic provided by the 3GPP interface, which
already knows e.g. whether the registration was automatic or the
actual requested operator id in case of being manual.
This will also make the u-blox plugin use the common +COPS set command
implemented in the broadband modem object, which has the fallback to
use the MCCMNC encoded in the current charset if needed.
Also, make sure we enable/disable the voice related unsolicited events
in both primary and secondary ports, because it may happen that the
primary port is connected with PPP and we're using the secondary port
for control.
If load_current_bands_finish() returns a NULL GArray, we must set the
GError or otherwise the daemon will segfault when the caller
dereferences the GError:
current_bands = MM_IFACE_MODEM_GET_INTERFACE (self)->load_current_bands_finish (self, res, &error);
if (!current_bands) {
/* Errors when getting current bands won't be critical */
mm_warn ("couldn't load current Bands: '%s'", error->message);
g_error_free (error);
}
This may happen with an empty but balid +UACT response, e.g.:
AT+UACT?
+UACT: ,,,
OK
Or when it replies a full empty string:
AT+UACT?
OK
When configuring these modems with AT+UUSBCONF=2, i.e. CDC-ECM + 4x
CDC-ACM, they also enumerate with a different PID on the USB. We need to
adjust the udev rules for that case in order to ignore the non-AT ports.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
This patch fixes several invalid checks like this:
array[i] && i < G_N_ELEMENTS (array)
which should instead be:
i < G_N_ELEMENTS (array) && array[i]
to avoid an out-of-bounds access of the array.
Fixes: c1aa658802
We were filtering the 4G bands supported by the module when parsing
+UBANDSEL responses, e.g. so that we would not reply unsupported bands
for a given ubandsel value.
But we need the same filtering in 2G and 3G bands, because for example
some modules may support a specific 4G band with a given ubandsel
value, but NOT the associated 3G band. E.g. the TOBY-R200 supports
EUTRAN-4 but not UTRAN-4.
We cannot have the ubandsel value comparision inside the for(;;) stop
conditions, because that would mean the loop would stop whenever the
comparison fails. We want to look for a value, so we need to loop the
whole array and stop once we find it only.
