If a feature like Wi-Fi, OVS, team, etc. is disabled or no longer
supported, it is better to report an error when the connection is
added via nmcli than accepting the connection and complaining later
about a "missing plugin"; there is no plugin and the connection will
never be able to activate.
Example errors now:
# nmcli connection add type team
Error: Failed to add 'team-nm-team' connection: team support is disabled in this build
# nmcli connection add type gsm
Error: Failed to add 'gsm' connection: WWAN support is disabled in this build
# nmcli connection add type wimax nsp 00:99:88:77:66:55
Error: Failed to add 'wimax' connection: WiMAX is no longer supported
Note that we don't touch libnm-core (the part defining the settings
and properties), as that defines the API of NetworkManager. The API
should not change according to compile flags.
When authenticating via 802.1X, the supplicant must be made aware of
the bridge the interface is attached to. This was already done for
wifi in commit ae31b4bf4e ('wifi: set the BridgeIfname supplicant
property when needed'). When setting the BridgeIfname property, the
supplicant opens an additional socket to listen on the bridge, to
ensure that all incoming EAPOL packets are received.
Without this patch, the initial authentication usually works because
it is started during stage2 (prepare), when the device is not yet
attached to the bridge, but then the re-authentication fails.
Note: I could reproduce the problem only when the bridge is configured
with bridge.group-forward-mask 8.
Resolves: https://issues.redhat.com/browse/RHEL-121153https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2301
Document a known limitation that we delete bridges and ports from ovsdb
when we remove their last NM-owned attached port or interface, even if
other externally added ports or interfaces exist.
The commit linked below introduced a bug that caused that OVS ports
added externally to NM are always deleted when we delete any OVS
interface. It affects to all externally added ports, including those
that are not related to the deleted interface and even those in
different OVS bridges.
Fix it by only modifying ports and bridges that are ascendants of the
deleted interface, leaving everything else untouched.
Note that bridges and ports still need to have at least one NM-managed
interface, otherwise they will also be purged. For example, an NM-owned
OVS bridge with 2 ports+iface, one NM-owned and one external: if we
delete the NM-owned iface, both ports and the bridge will be deleted.
For now, this is a known limitation that is not being fixed here.
Fixes: 476c89b6f2 ('ovs: only keep bridges and ports with NM interfaces attached')
We've had a few rare instances where a modem stopped retrying
to autoconnect because it briefly didn't have an operator code.
This isn't a permanent failure, so we shouldn't abort completely
for it.
This property allows the user to optionally configure
an interlink name on a HSR interface, so that it could
serve as RedBox (Redundant Box) by connecting DAN (dual
attachment node) to SAN (single attachment node).
This property allows the user to set the protocol
version when using HSR. Currently, the property
supports two values - `2010` (referred to as HSRv0
in the kernel), and `2012` (HSRv1).
We must do different cleanups depending on the CleanupType. Document the
meaning of the different types as it was very confusing to work on new
code without having very clear what do they mean.
The flag is used for both sleeping and networking disabled conditions.
This is because internally they share logic, but it's not obvious for
users and it has caused confusion in the past when investigating why
devices didn't become managed. Make it explicit that it can be because
of either reason.
It would be better to create two separate flags, actually, and it
doesn't seem complex, but better not to risk introducing bugs for that
little benefit.
Logs before:
device (enp4s0): state change: disconnected -> unmanaged (reason 'unmanaged-sleeping' ...
Logs before:
device (enp4s0): state change: disconnected -> unmanaged (reason 'unmanaged-nm-disabled' ...
When we disable networking with `nmcli networking off` the reason that
is logged is "sleeping". Explain instead that networking is disabled.
Before:
device (lo): state change: activated -> deactivating (reason 'sleeping' ...
After:
device (lo): state change: activated -> deactivating (reason 'networking-off' ...
When we do `nmcli networking off` it's shown as state "sleeping". This
is confusing, and the only reason is that we share internally code to
handle both situations in a similar way.
Rename the state to the more generic name "disabled", situation that can
happen either because of sleeping or networking off.
Clients cannot differentiate the exact reason only with the NMState value,
but better that they show "network off" as this is the most common reason
that they will be able to display. If the system is suspending, there will
be only a short period of time that they can show the state, and showing
"network off" is not wrong because that's what NM has done as a response
to suspend.
In the logs, let's make explicit the exact reason why state is changing
to DISABLED: sleeping or networking off.
Logs before:
manager: disable requested (sleeping: no enabled: yes)
manager: NetworkManager state is now ASLEEP
Logs after:
manager: disable requested (sleeping: no enabled: yes)
manager: NetworkManager state is now DISABLED (NEWORKING OFF)
State before:
$ nmcli general
STATE ...
asleep ...
State after:
$ nmcli general
STATE ...
network off ...
In some cases it is necessary to set a custom DHCP client-id during
early boot. For example, the firmware of some InfiniBand NIC uses a
48-bit MAC derived from the InfiniBand 20-byte MAC when doing
PXE. NetworkManager doesn't have any knowledge of that 48-bit MAC and
uses the full MAC as client-id, therefore getting a different lease.
Introduce a new option 'rd.net.dhcp.client-id' to specify a custom
client-id.
Resolves: https://issues.redhat.com/browse/RHEL-108454https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2277
When reading NetworkManager.conf and NetworkManager-intern.conf we might
need to know if a group is defined or not, even if it's empty. This is
the case, for example, for [global-dns]. If [global-dns] is defined in
NM.conf overwrites the config from NM-intern, and if it's defined in any
of them they overwrite the configs from connections.
Before this patch, defining it as an empty group was ignored:
```
[global-dns]
```
Instead, it was necessary to add at least one key-value to the group.
Otherwise the group was silently ignored.
```
[global-dns]
searches=
```
Keep empty groups so we can take better decissions about overwritting
configs from other sources.
Clients like nmstate needs to know if the [global-dns] section is
defined or not, so they know if DNS configs from connections are
relevant or not. Expose it in D-Bus by always exposing "searches"
and "options" if it's defined, maybe as empty lists.
According to the documentation, settings from [global-dns] (searches and
options) are always merged with those from connections. However this was
not happening if no [global-dns-domain-*] exists, in which case
connections were ignored. This happened because in the past both global
sections must de defined or undefined. When this was changed to allow
defining only [global-dns], allowing it in the function that generates
the resolv.conf file was forgotten. Fix that now.
Anyway, merging these configs doesn't make much sense. The searches and
options defined in connections probably make sense only for the nameservers
defined in that same connection.
Because of this, make the following change: if global nameservers are
defined, use searches and options from [global-dns] only, because those
defined in connections may not make sense for the global nameservers. If
[global-dns] is missing, assume an empty [global-dns] section.
Also, if no global nameservers are defined, but [global-dns] is, make
that it overwrites the searches and options defined in connections. This
is not ideal, but none of the alternatives is better and at least this
is easy to remember.
So, the resulting rules from above are:
- If [global-dns] is defined, it always overwrite searches and options
from connections.
- If [global-dns-domain-*] is defined, it always overwrite nameservers
from connections. It overwrites searches and options too.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
Fixes: f57a848da5 ('man: update documentation about global DNS configuration')
Since 1.44 we accept a global-dns section without any global-dns-domain
section, so users can define searches and options without defining any
global DNS servers.
When set from the D-Bus API it was still rejected. Fix it.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
NM_SETTING_BOND_OPTION_LACP_ACTIVE is flagged as BOND_OPTFLAG_IFDOWN in
the kernel and hence should not be in OPTIONS_REAPPLY_SUBSET.
Authored-by: Mohith Kumar Thummaluru <mohith.k.kumar.thummaluru@oracle.com>
Signed-off-by: Mohith Kumar Thummaluru <mohith.k.kumar.thummaluru@oracle.com>
Signed-off-by: Pradyumn Rahar <pradyumn.rahar@oracle.com>
