For infiniband, request_broadcast is automatically (and always) enabled.
Otherwise, we usually don't enable it, and (unlike systemd-networkd),
there is currently no configuration option to enable it.
Still honor the new udev property that can indicate to enable the flag
per device.
See-also: https://github.com/systemd/systemd/pull/ ### 19346
The DHCP client has potentially a large number of options,
including boolean options (flags). It is cumbersome to implement
them one by one. Instead, make more prominent use of NMDhcpClientFlags.
Previously, we used nm_udev_utils_property_as_boolean(), which was
taken from g_udev_device_get_property_as_boolean(). That function
accepts "1" and "true" (with ASCII case insensitive).
When we parse a flag, there is no need to reject "no", "yes" or
"on"/"off" as invalid (and thus return FALSE). We have a boolean
parse method _nm_utils_ascii_str_to_bool(), which parses everything
that nm_udev_utils_property_as_boolean() accepts, and more.
Be liberal in what we accept, so use our general parse function.
g_key_file_set_comment() has slightly weird API that will fail to set a
comment if it doesn't find the group. This is the case here since we
haven't set any strings under the [Security] group yet.
Fixing this is kind of ugly, so for now just don't add that comment in
the case where we don't have the [Security] group.
There are cases where the settings didn't actually change and we just
want to ensure NM and iwd settings are in sync (one such case would be
when a setting was changed while iwd wasn't running, here we want to
synchronize all settings when starting up iwd).
We're already doing this and calling sett_conn_changed() from
mirror_connection() on all connections after adding an interface, the
actual settings synchronization code doesn't get executed though because
we're passing 0 as update_reason, which means we bail out early from
sett_conn_changed().
To make sure we actually update the iwd network configurations in that
case, too, pass UPDATE_REASON_UPDATE_NON_SECRET as the update reason to
sett_conn_changed(), which is the correct update reason in this case.
Quite obviously, we want to update the AutoConnect setting of the iwd
network in case the NM and iwd settings differ, not if they are the
same. So check for unequality here instead of equality, which fixes the
AutoConnect setting's synchronization.
Fixes: 4229c97012 ('iwd: Mirror NM connections to IWD network config files'):
The macro always overwrites LIBS and the result is that every binary
links against libreadline.
Instead, save the library to READLINE_LIBS.
See also: 94274c6fcd ('build: fix wrongly linking against libreadline in all applications')
Fixes: af360238be ('m4/ax_lib_readline.m4: Update after running aclocal')
Apparently moving secrets between priv->connection and
priv->system_secrets in the various places throughout
NMSettingsConnection is no longer needed and has no effect on the
state of the D-Bus object or the gobject visible from outside. It
seems that it was needed for the secrets handling in NMDevice
subclasses before the introduction of the applied connection concept
but now nm_connection_need_secrets() is called in those subclasses
directly on the applied connection object and the secrets obtained
from multiple nm_settings_connection_get_secrets calls are also
collected directly in the applied connection's settings.
Drop the system secrets cache mechanism as a cause of a minor memory
overhead, some code overhead and also a source of some unneeded gobject
signals as the connection settings were being updated.
Note: the NM_SETTINGS_CONNECTION_UPDATE_REASON_CLEAR_SYSTEM_SECRETS and
NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_SYSTEM_SECRETS flags in the
SettingsConnection update signals appear to only have been used by the
SettingsConnection internally to keep priv->system_secrets up to date.
They can have potential other uses in the handlers of those signals so I
kept them. Unlike some of the other NMSettingsConnectionUpdateReason
values these are actual update *reasons* and not flags telling the
settings backends how to handle a specific change in the settings.
All usages of nm_settings_connection_clear_secrets() outside of the
NMSettingsConnection implementation were setting the
clear_cached_system_secrets parameter to FALSE which meant that the
operation was a no-op since the system-secrets cache kept a copy of the
secrets being cleared and any access to the SettingsConnection through
the D-Bus API or the class methods would behave the same as without the
call, with the exception of directly reading the settings from the
result of nm_settings_connection_get_connection(). The calls would
still generate D-Bus and gobject signals however, which were redundant.
Drop the method and its calls from the rest of NM code as not needed and
potentially confusing. The comments preceding these calls implied that
they were needed so that the next activation attempt would be forced to
use nm_settings_connection_get_secrets() but this was the case probably
only before the applied connection concept was introduced.
Also drop two nm_active_connection_clear_secrets() uses in
NMVpnConnection, right before the teardown of the active connection,
that could only possibly have any effect if they affected the
NMSettingsConnection, but as mentioned earlier the
nm_settings_connection_clear_secrets() use inside
nm_active_connection_clear_secrets() didn't do anything and is now
removed.
The one internal use of nm_active_connection_clear_secrets() in the
D-Bus ClearSecrets() implementation is inlined.
This patch is introducing the wired setting accept-all-mac-addresses
property. The value corresponds to the kernel flag IFF_PROMISC.
When accept-all-mac-address is enabled, the interface will accept all
the packets without checking the destination mac address.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Having two functions like link_set_x() and link_set_nox() it is not a
good idea. This patch is introducing nm_platform_link_change_flags().
This allow flag modification directly, so the developer does not need to
define the virtual functions all the time everywhere.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
This patch is introducing NM_DEVICE_INTERFACE_FLAG_PROMISC in
interface_flags. The flag represents IFF_PROMISC kernel flag.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Allow IP prefixes of 0 for routing rules, which are used for specifying a
route for all traffic. (e.g. route all traffic by default with separate
rules to exclude specific IP ranges)
#711
When the link goes away the manager keeps software devices alive as
unrealized because there is still a connection for them.
If the device is software and has a NM-generated connection, keeping
the device alive means that also the generated connection stays
alive. The result is that both stick around forever even if there is
no longer a kernel link.
Add a check to avoid this situation.
https://bugzilla.redhat.com/show_bug.cgi?id=1945282
Fixes: cd0cf9229d ('veth: add support to configure veth interfaces')
We need to handle the case that kernel mangles the configured values. We
already do, but there was a left over nm_platform_lnk_bridge_cmp() that
is still wrong.
Related: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/665
Fixes: ce9211500e ('platform/tests: work around rounding errors for bridge values in unit tests')
The code never set "iface_get_config->cidr_addr", despite
setting "cidr_prefix" and "has_cidr". As a result, cloud-setup
would think that the subnet is "0.0.0.0/$PLEN", and calculate
the gateway as "0.0.0.1".
As a result it would add a default route to table 30400 via 0.0.0.1,
which is obviously wrong.
How to detect the right gateway? Let's try obtain the subnet also via
the meta data. That seems mostly correct, except that we only access
subnet at index 0. What if there are multiple ones? I don't know.
https://bugzilla.redhat.com/show_bug.cgi?id=1912236
This ensures that the argument is some pointer to pointer. This gives a
bit of additional compile time safety, but in general, it still casts
any pointer to pointer (because that's what we require, as most arguments
won't be of type NMDBusObject to begin with).
NM should have been creating the IWD network config files with 0600
permission bits from the beginning since they can contain secrets.
g_key_file_save_to_file() uses 0666 which shouldn't be used even for the
temporary file before setting the final permissions.
Also try to preserve the last modification timestamp of the original
file because it is currently used by IWD when ranking networks for
autoconnect and updating it everytime NM rewrites the file could
potentially affect autoconnect priorities.
