Using g_file_set_contents() makes it impossible to write a proper
SELinux policy because the function creates a file with a random
suffix, and SELinux file transitions can't match on wildcards.
Use a fixed temporary file name. In this case it's fine because
/run/NetworkManager is only writable by root and NetworkManager is the
only process writing into it.
These lines says things like "changed a bridge", what seems to mean that
NM is doing the change. Actually, these logs indicate changes that NM is
being notified of, and they may even be external changes.
- Add the "monitor:" prefix to show that it's something that NM is
monitoring, not doing.
- Say "bridge changed" instead of "changed a bridge", which sounds an
action that we're doing.
- Print the bridge/port/iface name first, instead of the uuid-like key which
is not useful for a quick look by a human.
- Print `connection=conn-uuid` instead of just `conn-uuid`, as it's not
obvious that the uuid refers to the connection.
Before:
ovsdb: obj[bridge:8c975244-cb0a-4add-8901-c398dcbc27d6]: changed a bridge: br-int, b1ef934d...
After:
ovsdb: monitor: br-int: bridge changed: obj[bridge:8c975244-cb0a-4add-8901-c398dcbc27d6], connection=b1ef934d...
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.
