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.
The new QCDM port probing and grabbing mechanism implements a new
property for detecting the plugins which require the QCDM port to
be probed and grabbed.
Add the property to the affected plugins.
g_date_time_new, and g_date_time_new_utc return NULL if inputs are out
of range, and currently mm_new_iso8601_time passes the GDateTime created
by those two functions to date_time_format_iso8601 without checking for
NULL values, causing a g_date_time_format_iso8601 crash if PDU data is
corrupted with wrong date.
To prevent this, mm_new_iso8601_time now can return NULL and set a new
GError if GDateTime created by g_date_time_new is NULL.
Fixes#546
==99766== 96 (24 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 3,791 of 4,243
==99766== at 0x483E7C5: malloc (vg_replace_malloc.c:380)
==99766== by 0x50DCAC9: g_malloc (gmem.c:106)
==99766== by 0x50F46D6: g_slice_alloc (gslice.c:1069)
==99766== by 0x50CE9F2: g_list_insert_sorted_real (glist.c:1109)
==99766== by 0x753DE92: ???
==99766== by 0x753E6D4: ???
==99766== by 0x753E897: ???
==99766== by 0x1F059D: mm_plugin_create_modem (mm-plugin.c:922)
==99766== by 0x166693: mm_device_create_modem (mm-device.c:481)
==99766== by 0x161547: device_support_check_ready (mm-base-manager.c:219)
==99766== by 0x4F03533: g_task_return_now (gtask.c:1219)
==99766== by 0x4F07078: UnknownInlinedFun (gtask.c:1289)
==99766== by 0x4F07078: g_task_return (gtask.c:1245)
There are modems out there, that reuse the same vid:pid for multiple
USB layouts, so there may be port type hints that are not really
applicable in all layouts.
E.g. the EM7565 in MBIM layout uses interface #0 for the MBIM port,
while in QMI layout it uses interface #0 for the QCDM port (which is
what the port type hint included in MM states). With these rules, if
we don't bind the port type hint to TTY ports only, we would be
wrongly flagging the MBIM port as possible QCDM port:
<debug> [plugin/sierra] probes required for port cdc-wdm0: 'mbim'
<debug> [cdc-wdm0/probe] no AT/QMI/MBIM probing in possible QCDM port
<debug> [cdc-wdm0/probe] port is not AT-capable
<debug> [cdc-wdm0/probe] port is not QMI-capable
<debug> [cdc-wdm0/probe] port is not MBIM-capable
<debug> [cdc-wdm0/probe] port probing finished: no more probings needed
Avoid this, by making sure all port type hints are added exclusively
to TTY ports. It's not a perfect solution, but it's enough for the
known cases.
Some of the AT-based connection methods don't have any way to query
connection status, or we don't have a proper implementation for those
yet. Ignore the reload operation in all those.
By default, fallback to "unknown" mobile equipment error when the
modem gets disconnected by the network and we don't have any way to
know a more detailed reason.
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.
We already have methods to query for interface specific attributes
like class/subclass/protocol, so add a new one for the interface
number, and make sure we use ATTRS{bInterfaceNumber} to load it
always, instead of assuming the ID_USB_INTERFACE_NUM property is set.
If the conversion is not fully compatible, the user of the method
needs to request transliteration enabled explicitly in order to avoid
returning errors in this method.
Until now, this method would automatically apply transliteration;
i.e. replacing characters with '?' when no direct translation was
available.
We can attempt to do that transliteration on strings that are not
critical, e.g. the operator name reported by the network. But we
should not do that on other types of strings, e.g. on SMS contents
that may really have additional purposes than just being
human-readable.
This commit makes the transliteration option to be explicitly
requested by the caller.
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
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
This patch removes all monitoring of the 'usb' subsystem completely,
which is anyway a valid subsystem but for which we shouldn't need any
special handling. Right now, with newer kernels, we were using that
monitoring exclusively to get notified of full USB device remove
events, which is really not required as we already process the port
removals one by one.
We simplify the logic everywhere that attempted to match either the
'usb' or 'usbmisc' subsystems, and we no longer require the explicit
checks for the port name being named 'cdc-wdm[0-9]*' in the code, as
that is already taken care of by the ID_MM_CANDIDATE udev tag rule.
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
So, rename the port subsystem type enumn to 'usbmisc'.
The numbers associated to each port mode given by the AT^GETPORTMODE
response are not USB interface numbers, they are 'port numbers'.
Moreover, these numbers may start either at 0 or at 1, depending on
the firmware.
The only reasonable way to parse this response is to just gather the
order of all the port modes reported, and apply the modes to each
serial port found in the system in the same order.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/239
We will use one single method to apply port type hints, not a mix of
them:
* If AT^GETPORTMODE is supported, prefer its hints over any other
method.
* Otherwise, try to guess hints from USB interface descriptions.
* And if none of the plugin-specific hints are supported, we'll
default to applying generic port type hints from udev tags.
Once the hints have been applied by one of the methods above, the
fallback hint sequences are run:
* Flag the first cdc-wdm port as primary if no other port has been
flagged as primary.
* Flag the USB interface 0 as PPP if no other port type hint has
been set in any other port.
The logic applying all these procedures has been refactored so that we
have separate functions for each, which is much easier to read and
follow, even if it requires multiple iterations over the port probe
list.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/238
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
Extended the ModemManager Signal interface to include 5G signal
information for RSRP, RSRQ and SINR via libqmi. Also extended mmci
to print 5G signal info.
Instead of using the FALSE return of the method to indicate either a
fatal error (if result_error was set) or the continuation request (if
result_error wasn't set), provide a enum that has explicit states for
all three possible values (failure, success or continue).
Running NDISDUP=1,0 on an already disconnected bearer/context will
report ERROR, so we can really ignore the result of the command,
because we're anyway going to get the correct bearer/context status
later on with the NDISSTATQRY checks.
When a network-initiated event is received telling us that a
bearer/context is disconnected, we should handle and process it right
away, without thinking on whether there is going to be a
user-requested disconnect afterwards or not.
This effectively reverts the changes introduced in commit
21a5aaf4fe, which looks like was done to
handle synchronization issues with upper layers (e.g. with
NetworkManager or Shill).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/205
We can safely cast the data in a GArray to gpointer first, and then
to the pointer type we require.
huawei/mm-broadband-modem-huawei.c: In function 'set_current_bands':
huawei/mm-broadband-modem-huawei.c:916:50: error: cast increases required alignment of target type [-Werror=cast-align]
bands_string = mm_common_build_bands_string ((MMModemBand *)bands_array->data,
^
