Avoid a deprecation warning with too new glib:
../libmm-glib/mm-common-helpers.c: In function ‘date_time_format_iso8601’:
../libmm-glib/mm-common-helpers.c:1729:5: warning: ‘g_date_time_format_iso8601’ is deprecated: Not available before 2.62 [-Wdeprecated-declarations]
1729 | return g_date_time_format_iso8601 (dt);
| ^~~~~~
This call site is protected by version guards and provides an alternative
implementation in date_time_format_iso8601().
It requires newer glib than we do:
../libmm-glib/mm-common-helpers.c: In function ‘mm_new_iso8601_time’:
../libmm-glib/mm-common-helpers.c:1787:9: warning: ‘g_time_zone_new_offset’ is deprecated: Not available before 2.58 [-Wdeprecated-declarations]
1787 | tz = g_time_zone_new_offset (offset_minutes * 60);
| ^~
In file included from /usr/include/glib-2.0/glib/gdatetime.h:33:
/usr/include/glib-2.0/glib/gtimezone.h:67:25: note: declared here
67 | GTimeZone * g_time_zone_new_offset (gint32 seconds);
| ^~~~~~~~~~~~~~~~~~~~~~
Let's not use the routine with older versions of glib.
The g_date_time_new_from_unix_utc() method in glib2 may fail if the
given timestamp is too far into the future. The value is supposed to
be seconds since unix time origin, but internally it will be converted
into usecs, so any value longer than G_MAXINT64 / USEC_PER_SECOND
isn't allowed.
This is currently used in the CLI, and we're anyway ignoring the error
returned in that case, but at least it won't crash if it ever happens.
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
It stores the epoch timestamp of the current bearer session start.
If there is no connected bearer, it is set to 0 and not displayed
in mmcli output.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Includes updates by Aleksander Morgado to fix coding style issues.
The support of autoptr for GEnumClass and GFlagsClass was introduced in
glib 2.58. To keep compatibility with glib 2.56, declare the autoptr
cleanup functions.
Fixes#397
This new property will provide detailed information about the failed
connection attempt, or about the network initiated disconnection. The
property will be cleared only if a new connection attempt is
triggered, and so it can be used to investigate why a given attempt
failed without needing to be the one who triggered the attempt (e.g.
so that failures in NetworkManager-triggered connection attempts can
be investigated looking at the DBus API).
The property is built as a (ss) tuple, but the libmm-glib interface
provides methods to read this property as a GError.
mm-common-helpers.c: In function 'mm_get_int_from_str':
mm-common-helpers.c:1349:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (eol == num)
^~
mm-common-helpers.c: In function 'mm_utils_hexstr2bin':
mm-common-helpers.c:1718:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < len; i += 2) {
^
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.
Both the Simple.Connect() and Modem.CreateBearer() are updated to
allow a new 'multiplex' setting in the properties provided by the user
in both of these methods.
The new setting expects a MMBearerMultiplexSupport enum indicating
what kind of multiplex needs the user has:
* none: if multiplex must not be used.
* requested: if multiplex should be used if available.
* required: if multiplex must be used.
The underlying implementations will take care of accepting or
rejecting the setting depending on the system and modem capabilities.
It's not uncommon that we may want to parse a simple AT response that
contains a single number by doing mm_strip_tag() followed by
mm_get_uint_from_str(). In order to do this, we need to have the
helper methods that convert strings to numbers support \r\n characters
at the end of the string, as we would have in AT responses.
E.g. so that the settings passed on Simple.Connect() or
Bearer.Connect() are parsed correctly from the user string:
daemon.notice netifd: wan (30476): simple connect=apn=internet,ip-type=ipv4,allow-roaming=yes
daemon.notice netifd: wan (30476): Error parsing connect string:
'Invalid properties string, unexpected key 'allow-roaming''
This also goes inline with e.g. the --create-bearer help in the man
page that suggests using yes/no for the allow-roaming setting.
And added support for several new things, including:
* Setting "any" band now attempts to set all supported bands.
* Added new 2G band value '5' (egsm+dcs+pcs+g850).
* Setup support for two different 3G band combinations, a default one
plus an alternate one applicable to the LM940/960 models only. The
alternate combination is selected via udev tags.
During the refactor, the following Telit-specific helpers were also
removed and exchanged with more generic counterparts.
* mm_telit_bands_contains() -> mm_common_bands_garray_lookup()
* mm_telit_get_band_flags_from_string() -> mm_parse_uint_list()
The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g.
section 4.3 in v10.3.0):
* PS mode 1: EPS only, 'voice centric'
* PS mode 2: EPS only, 'data centric'
* CS/PS mode 1: EPS and non-EPS, 'voice centric'
* CS/PS mode 2: EPS and non-EPS, 'data centric'
The mode specifies, among other things, how the UE should behave w.r.t
CS fallback depending on the capabilities reported by the network.
So that we don't leak the port names allocated within each
MMModemPortInfo.
==261== 672 bytes in 84 blocks are definitely lost in loss record 7,314 of 7,383
==261== at 0x402C51E: malloc (vg_replace_malloc.c:299)
==261== by 0x4484878: g_malloc (gmem.c:94)
==261== by 0x449D51D: g_strdup (gstrfuncs.c:363)
==261== by 0x44B5B73: g_variant_dup_string (gvariant.c:1529)
==261== by 0x44B945E: g_variant_valist_get_nnp (gvariant.c:4775)
==261== by 0x44B945E: g_variant_valist_get_leaf (gvariant.c:4945)
==261== by 0x44B945E: g_variant_valist_get (gvariant.c:5126)
==261== by 0x44B922C: g_variant_valist_get (gvariant.c:5161)
==261== by 0x44B9FC9: g_variant_get_va (gvariant.c:5388)
==261== by 0x44BA3C5: g_variant_get_child (gvariant.c:5486)
==261== by 0x6613FA8: mm_common_ports_variant_to_garray (mm-common-helpers.c:238)
==261== by 0x6601AB9: ensure_internal_ports (mm-modem.c:766)
==261== by 0x6603E42: mm_modem_peek_ports (mm-modem.c:825)
==261== by 0x65CD94D: owns_port (nm-modem-broadband.c:196)
Reported-by: Piotr Figiel <p.figiel@camlintechnologies.com>
Instead of relying on the udev daemon and GUDev to manage the devices reported
by the kernel, we can now run ModemManager relying solely on the kernel events
reported via the new ReportKernelEvent() API. Therefore, the '--no-auto-scan'
option is implicit for the ModemManager daemon when udev is disabled in the
build.
Additionally, a new custom implementation of the kernel device object is
provided, which uses sysfs to load the properties and attributes required in
each kernel device, instead of using a GUdevDevice.
The udev rule files are kept in place, and a simple custom parser is provided
which preloads all rules in memory once and then applies them to the different
kernel objects reported via ReportKernelEvent(), e.g. to set port type hints.
A simple unit test setup is prepared to validate the udev rules during the
`check' Makefile target.
We may want to use the mm_get_()_from_match_info() calls to read optional items,
so that the method returns FALSE if the item index doesn't apply. So, avoid the
implicit warning issued by g_return_val_if_fail().
The "0" case wasn't being handled properly:
$ sudo mmcli -m 0 --create-bearer="apn=,allow-roaming=0"
Error parsing properties string: 'Cannot get boolean from string '0''
