It is possible that we learn the link is ready on stage3_ip_config
rather than in link_changed event due to a stage3_ip_config scheduled by
another component. In such cases, we proceed with IP configuration
without allocating the resources needed like initializing DHCP client.
In order to avoid that, if we learn during stage3_ip_config that the
link is now ready, we need to schedule another stage3_ip_config to
allocate the resources we might need.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2004
Fixes: 83bf7a8cdb ('ovs: wait for the link to be ready before activating')
If we add multiple default routes with the same metric and different
preferences, kernel merges them into a single ECMP route, with overall
preference equal to the preference of the first route
added. Therefore, the preference of individual routes is not
respected.
To avoid that, add routes with different metrics if they have
different preferences, so that they are not merged together.
We could configure only the route(s) with highest preference ignoring
the others, and the effect would be the same. However, it is better to
add all routes so that users can easily see from "ip route" that there
are multiple routers available.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1468https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1983
Fixes: 032b4e4371 ('core: use router preference for IPv6 routes')
When activating an ovs-interface we already wait for the cloned MAC
address to be set, ifindex is present and platform link also present but
in some cases this is not enough.
If an udev rule is in place it might modify the interface when it is in
a later stage of the activation causing some race conditions or
problems. In order to solve that, we must wait until the link is fully
initialized.
We are currently asserting that the list of devices waiting for
auto-activation in NMPolicy is not empty. This condition is always
false because:
- NMDevice holds a reference to NMManager
- NMManager holds a reference to NMPolicy
- on dispose, NMDevice asserts that it's not in NMPolicy's
auto-activate list
Therefore if there is any NMDevice alive, NMPolicy must be alive as
well. Instead, if there is no NMDevice alive the list must be empty.
The assertion could fail only when the NMPolicy instance gets
disposed, which usually doesn't happen because it's still referenced
at shutdown.
Fixes: aede228974 ('core: assert that devices are not registered when disposing NMPolicy')
When activating a port with its controller deactivating by new
activation, NM will register `state-change` signal waiting controller to
have new active connections. Once controller got new active connection,
the port will invoke `nm_active_connection_set_controller()` which lead
to assert error on
g_return_if_fail(!nm_dbus_object_is_exported(NM_DBUS_OBJECT(self)))
because this active connection is already exposed as DBUS object.
To fix the problem, we remove the restriction on controller been
write-only and notify DBUS object changes for controller property.
Signed-off-by: Gris Ge <fge@redhat.com>
It's deprecated. Warn any time it is being considered for loading,
instead of at load time, so that the user gets a warning when they got
the plugin in configuration, even if it's build time disabled.
https://issues.redhat.com/browse/RHEL-24622
Prioritize internal, which is what most people should be using. Try
dhclient last, so that it's not attempted when not explicitly
configured or everything else fails.
Make it off by default. Point out it's deprecated in a config summary.
It's not maintained upstream. There's probably not much justification for
using it any more and we'd like to remove it at some point.
https://issues.redhat.com/browse/RHEL-24622
Make it off by default. Point out it's deprecated in a config summary.
It's not maintained upstream. There's probably not much justification for
using it any more and we'd like to remove it at some point.
https://issues.redhat.com/browse/RHEL-24622
At the moment, the access point mode uses 20MHz channels. Introduce a
new 'wifi.channel-width' property that allows the use of a larger
bandwidth, thus increasing performances.
Instead of asking the Wi-Fi password in advance (or not at all, if we're
creating a new connection for "nmcli d conn"), use the secret agent.
This makes things consistent with other places where we handle the secrets
for an activating connection in nmcli ("nmcli c up", "nmcli d con" with
an existing connection).
This also fixes the situation where the secrets would stop being
required, such as on enrollment via WPS button press on a router.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1960
Script to create a RHCOS custom image containing a NetworkManager rpm from
a copr repository.
In order to have a custom RHCOS image, we cannot modify the image itself but
we can add a custom layered image that includes all RHCOS functionality and
adds additional functionality to it.
Requirements:
- A quay.io registry where you have push access.
- You must have your pull-secret in the same directory where the script is
being run. You can download your pull-secret from:
https://console.redhat.com/openshift/install/pull-secret
In order to install this on nodes from a cluster that already exists it must
be done using MachineConfig operator. In essence the following YAML file
must be created.
```
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: <role>
name: os-layer-custom-nm
spec:
osImageURL: <registry>
```
Please, notice that the role and registry need to be set to your needs.
Then, it can be applied by:
$ oc create -f <yaml file>
Finally, the machines will be ready once the field UPDATED has the True value
in the output of this command.
$ oc get mcp
Before introducing the hostname lookup via nm-daemon-helper and
systemd-resolved, we used GLib's GResolver which internally relies on
the libc resolver and generally also returns results from /etc/hosts.
With the new mechanism we only ask to systemd-resolved (with
NO_SYNTHESIZE) or perform the lookup via the "dns" NSS module. In both
ways, /etc/hosts is not evaluated.
Since users relied on having the hostname resolved via /etc/hosts,
restore that behavior. Now, after trying the resolution via
systemd-resolved and the "dns" NSS module, we also try via the "files"
NSS module which reads /etc/hosts.
Fixes: 27eae4043b ('device: add a nm_device_resolve_address()')
