Some warnings in the generation of the translation files indicate real
errors, like strings that cannot be extracted for translations. Check
that no warnings are emitted.
Detected thanks to this message when generating the pot files:
id.po:14392: warning: internationalized messages should not contain
the '\v' escape sequence.
Due to the formatting of the string that contains it, it seems clear
that the \v character and the preceding work was put there by mistake.
Glib format specifiers are not gettext friendly. It even emits a
warning: src/core/main-utils.c:196: warning: Although being used in a
format string position, the msgid is not a valid C format string."
One possible solution is to use the equivalent format specifiers from
<inttypes.h> like PRId64, available since C99.
Even simpler is to cast the value to a type that is big enough to hold
it according to C specs (i.e. for int64: long long).
Fixes: 50f34217f9 ('main: use _nm_utils_ascii_str_to_int64 instead of strtol for reading pid')
A SSID of zero length, really looks "empty". Let
nm_utils_is_empty_ssid() indicate so too.
This affects some places, that try to guess what a hidden SSID looks
like. In general, it seems that treating a length of zero as empty, is
suitable also then.
nm_utils_escape_ssid() uses a static buffer, which makes it non
thread-safe. We shouldn't have such API in libnm. We could improve that
by using a thread-local storage, but that brings overhead, for a
function that really isn't useful.
It's not useful, because the escaping is very naive. You are better
served with:
- nm_utils_ssid_to_utf8(): gives UTF-8, but looses information.
- nm_utils_bin2hexstr(): does not loose information, but makes the
name unreadable.
Maybe the best way to escape the SSID (which can be binary, but usually
is UTF-8), are the utf8safe functions. That is because it makes the
blob UFT-8, while not loosing/hiding any bytes (the escaping can be
reversed). This API is currently not exposed to the users, if there were
a need, then this could be done as a 3rd way for printing SSIDs.
However, nm_utils_escape_ssid() is bad either way. Deprecate.
Setting
wifi.cloned-mac-address="stable-ssid"
should generate the same SSID as
connection.stable-id="${NETWORK_SSID}"
wifi.cloned-mac-address="stable"
For that to work correctly, we need to post-process the generated stable
id.
Fixes: d210923c0f ('wifi: add "wifi.cloned-mac-address=stable-ssid"')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1813
Specially in the case of BEST_EFFORT it's not completely clear what each
flag means. For example: with BEST_EFFORT, in the case of partial
success should we return an error value or a success value?
Add some comments and documentation to clarify.
Check for invalid DNS, addresses and routes errors in the `_from_dbus`
functions. With NM_SETTING_PARSE_FLAGS_STRICT, stop parsing and return
error at first error. With NM_SETTING_PARSE_FLAGS_BEST_EFFORT don't
return any error and return the values of the list which are valid.
This is the same that was done in a previous commit for ipv4 properties.
Report an error if the data type of the address-labels received via DBus
is not the expected.
Also, fix the assignment of the labels to their corresponding addresses.
As they are matched by array position, if any invalid address was
received, the array of addresses that we generate is shorter than the
array of address-labels. We were not considering this so we were
assigning the address-labels to incorrect addresses. Fix it by moving the
assignment of the labels to _nm_utils_ip4_addresses_from_variant, where
we still have the information of what the original position in the array
the address had.
Invalid addresses received via DBUS were just ignored and filtered out,
only emitting a warning to the logs. If there were still some valid
addresses, those were configured and the client was unaware of the
errors. Only if there was not any valid address at all and method was
manual, an error was returned from `verify`, but not reflecting the
real cause:
ipv4.addresses: this property cannot be empty for 'method=manual'
Check for invalid addresses errors in the `_from_dbus` functions. With
NM_SETTING_PARSE_FLAG_STRICT, parsing is aborted on first error and
error is returned. With NM_SETTING_PARSE_BEST_EFFORT, we keep parsing
and set only the valid values.
Actually, the invalid addresses were dropped in a helper function that
converts from GVariant to NMIPAddress. As it is part of the public API,
we can't change now its signature to add the GError argument. Instead,
create a new internal function and call it from the public one. The
public function will ignore the error, as it was doing previously, but
it won't emit any warning to avoid spamming the logs (we don't even
know if ignoring the invalid values was intentional when calling the
function). The new internal function might be made public in
the future, deprecating the other, but probably it is not necessary
because clients are never going to receive invalid addresses from the
daemon.
Do the same as explained above for DNS entries and routes.
Also, fix the documentation of nm_utils_ip_routes_to/from_dbus, which
said that it accepts new style routes but described the old style ones.
With enabled assertions via LIBNM_CLIENT_DEBUG=WARN or
LIBNM_CLIENT_DEBUG=ERROR, still print the warning/error message to the
default destination, along the trace/debug messages.
For example, when you set LIBNM_CLIENT_DEBUG_FILE, then we want that
those messages end up in the file too, not only in g_log() output.
Also, g_warning() prints to stderr. If you set
LIBNM_CLIENT_DEBUG="WARN,trace,stdout", then we printed the warning to
stderr and the trace messages to stdout.
All debug messages should and up at the same place, and the g_warning()
and g_critical() messages are additional.
Also because glib's g_log() supports its own redirection and suppression
mechanism.
Previously, it was odd. The enum values like NML_DBUS_LOG_LEVEL_DEBUG were
actually the bit mask of all the levels "debug", "warn" and "error".
On the other hand, when parsing _nml_dbus_log_level, that variable only contained
the flags that were exactly requested. E.g. when setting LIBNM_CLIENT_DEBUG=trace,
then _nml_dbus_log_level only contained the trace flag 0x02. That was useful,
because with "LIBNM_CLIENT_DEBUG=warn,trace" the "warn" flag was not redundant,
it was used to enable printing via g_warning(). That was confusing.
Now, "LIBNM_CLIENT_DEBUG=warn,trace" is the same as "LIBNM_CLIENT_DEBUG=trace".
To enable printing via g_warning(), use "LIBNM_CLIENT_DEBUG=WARN,trace".
With this, we don't need this backward representation of the flags. Invert
it. The level enums are now just single bits.
Document LIBNM_CLIENT_DEBUG under nm_utils_print().
Also, add an alias "warn" for "warning" flag.
Also, no longer special treat "error" and "warning" flags to indicate
printing via g_criticial()/g_warning(). Previously, you could get
assertions via
$ G_DEBUG=fatal-warnings LIBNM_CLIENT_DEBUG=error,warning,trace nmcli
or you could enable all messages (including <error>/<warn> level)
without assertions via
$ G_DEBUG=fatal-warnings LIBNM_CLIENT_DEBUG=trace nmcli
However, it was not possible to enable only <error>/<warn> levels
without those assertions.
Now, "error"/"warn"/"warning" behave just like "debug"/"trace" to enable
message up to the specified level. It only implies printing to stderr
(or stdout or file, depending on "stdout" flag and
LIBNM_CLIENT_DEBUG_FILE).
Now, to enable redirect to g_warning()/g_error() use the new keywords
"ERROR"/"WARN"/"WARNING".
For testing, we probably want to enable such assertions. So to be
mostly backward compatible, we can run with
$ G_DEBUG=fatal-warnings LIBNM_CLIENT_DEBUG=error,warning,WARN nmcli
with that, the "error","warning" flags are redundant on newer libnm and
the WARN is ignored on older libnm.
This option was only introduced only to allow keeping the old behavior
in RHEL7, while the default order was changed from 'ifindex' to 'name'
in RHEL8. The usefulness of this option is questionable, as 'name'
together with predictable interface names should give predictable order.
When not using predictable interface names, the name is unpredictable
but so is the ifindex.
https://issues.redhat.com/browse/NMT-926https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1814
Now that we require glib 2.42, we can use G_PARAM_EXPLICIT_NOTIFY flag.
The benefit is that this flag saves a notification, when the property
value does not change.
The downside is, that implementations of set_property() must remember to
emit _notify() when required. This is somewhat alleviated by using
_nm_setting_property_set_property_direct(), which does this
automatically.
Se the flag for G_PARAM_EXPLICIT_NOTIFY for direct boolean properties.
For now, only do it for boolean properties, because of the danger of
getting this wrong. We must review all callers to make sure that they
don't implement set_properties() and don't forget to notify.
We will deprecate "connection.master" for "connection.controller". The
old property will become an alias for the new one. That means, when
setting the property we must emit notifications for both the old and the
new property.
Add "NMSettInfoProperty.direct_also_notify" for that. This is not fully
flexible, as it only works for direct properties (duh) and only allows
to specify one addtitional GParamSpec (of the same NMSetting). It is
however sufficient for our use.
We have nm_gobject_notify_together(), which accepts a list of
_PropertyEnums arguments. Add nm_gobject_notify_together_by_pspec(),
which can use a param spec.
direct_hook is a union, which currently only has one member (the set function
for a direct string). Extending this might make sense, for other set functions
(e.g. overwriting setting a strv array).
However, then the name was bad. The union is already for the set-function of
direct properties, it's not a place for various kinds of hooks (as it is
a union).
Rename.
"nm-glib" h contains compat wrappers for older glib versions. This file
used to be copied over to VPN plugins, to use the same compat code. It
was thus interesting to also have compat code for glib versions, that
were no longer supported by NetworkManager itself.
This was fine. But glib 2.42 is more than 8 years old. At this point,
there really is no need to support that, even if you copy the file out
of NetworkManager source tree.
Drop those compat wrappers.
The base image for the "check-tree" test got bumped to Fedora 39. This
brings a new python-black version (23.7.0 vs. 22.8.0) and requires
reformatting.
Maybe we should stick to 22.8.0, via `pip install`. But it seems better
to just follow the latest black version (the one from current Fedora).
So do the reformatting instead.
https://black.readthedocs.io/en/stable/change_log.html#id38
Let's not have unexpected, non-thread-safe functions somewhere deep down.
NML3ConfigData -- as a data structure -- is not thread-safe, nor aims it to
be. However, our code(!) should be thread-safe. That means, it should be
possible to call our code on separate data from multiple threads.
Violating that is a code smell and a foot gun.
This basically means that code should not access global data (unless
thread-local) or that the access to global-data needs to be
synchronized.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1806
- after modifying .gitlab-ci, the template must be regenerated by
running `ci-fairy generate-template`
- when swapping tier1 from f38 to f39, the list in tier2 must be updated
too.
Fixes: e2f04f0d2cc3 ('device: fix generated 'wifi.cloned-mac-address="stable-ssid"' for stable-id')
As Fedora 39 is officially out, we should use it in our gitlab-ci.
Please notice that this change will also update the
nm-code-format-container.sh to use Fedora 39 aswell.
This patch add support to HSR/PRP interface. Please notice that PRP
driver is represented as HSR too. They are different drivers but on
kernel they are integrated together.
HSR/PRP is a network protocol standard for Ethernet that provides
seamless failover against failure of any network component. It intends
to be transparent to the application. These protocols are useful for
applications that request high availability and short switchover time
e.g electrical substation or high power inverters.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1791
Dynamic added routes i.e ECMP single-hop routes, are not managed by l3cd
as the other ones. Therefore, they need to be tracked properly and
marked as dirty when they are.
Without this, the state of those ECMP single hop routes is not properly
tracked, and they are for example not removed by NML3Cfg when they
should.
Usually, routes to be configured originate from the combined
NML3ConfigData and are resolved early during a commit. For example,
_obj_states_update_all() creates for each such route an obj_state_hash
entry. Let's call those static, or "non-dynamic".
Later, we can receive additional routes. We get them back from NMNetns
during nm_netns_ip_route_ecmp_commit() (_commit_collect_routes()).
Let's call them "dynamic".
For those routes, we also must track an obj-state.
Now we have two reasons why an obj-state is tracked. The "non-dynamic"
and the "dynamic" one. Add two flags "os_dynamic" and "os_non_dynamic"
to the ObjStateData and consider the flags at the necessary places.
Co-authored-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
