Since both `NetworkManager.service` and `NetworkManager-initrd.service` are
allocated for the same bus name (`org.freedesktop.NetworkManager`) and this is
not allowed, the best option is to use a systemd generator to install them only
in the initrd, instead of setting fixed Install sections.
Fixes#1814
Restrict connectivity check DNS lookups to just the relevant link if the link
has a per-link DNS resolver configured. This change was previously discussed as
part of issue
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1836, and
brings NM's behavior back in line with the behavior documented in the man page.
The connectivity check checks for a per-link DNS resolver by querying
systemd-resolved's `ScopeMask` for the link; this involves a small D-Bus
roundtrip, but is ultimately the more flexible solution since it is also capable
of dealing with per-link DNS configuration stemming from other sources.
Fixes: e6dac4f0b6 ('core: don't restrict DNS interface when performing connectivity check')
By default, the MPTCP limits have 'add_addr_accepted' set to 0. It means
that when the other peer announces an additional address it can be
reached from, the receiver will not try to establish any new subflows to
this address. If this limit is increased, and without the new 'laminar'
flag, the MPTCP in-kernel path-manager will select the source address by
looking at the routing tables to establish this new subflow.
This is not ideal: very likely, the source address will be the one
linked to the default route and a new subflow from the same interface as
the initial one will be created instead of using another path.
This is especially problematic when the other peer has set the 'C-flag'
in the MPTCP connection request (MP_CAPABLE). This flag can be set to
tell the other side that the peer will not accept extra subflows
requests sent to its initial IP address and port: typically set by a
server using an anycast address, behind a legacy Layer 4 load balancer.
It sounds better to add the 'laminar' flag by default to pick the source
address from well-defined MPTCP endpoints, rather than relying on
routing rules which will likely not pick the most interesting solution.
Note that older kernels will accept unsupported flags, and ignore them.
So it is fine to have the new flag added by default even if it is not
supported.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
This new endpoint type has been recently added to the kernel in v6.18
[1]. It will be used to create new subflows from the associated address
to additional addresses announced by the other peer. This will be done
if allowed by the MPTCP limits, and if the associated address is not
already being used by another subflow from the same MPTCP connection.
Note that the fullmesh flag takes precedence over the laminar one.
Without any of these two flags, the path-manager will create new
subflows to additional addresses announced by the other peer by
selecting the source address from the routing tables, which is harder to
configure if the announced address is not known in advance.
The support of the new flag is easy: simply by declaring a new flag for
NM, and adding it in the related helpers and existing checks looking at
the different MPTCP endpoint. The documentation now references the new
endpoint type.
Note that only the new 'define' has been added in the Linux header file:
this file has changed a bit since the last sync, now split in two files.
Only this new line is needed, so the minimum has been modified here.
Link: https://git.kernel.org/torvalds/c/539f6b9de39e [1]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
It's possible that the first timeout gets delayed; therefore the
interval between the first and the second callback can be less than
one second, and the budget doesn't refill completely.
Schedule the second timeout from the first callback to guarantee that
at least one second passes between the callbacks.
Fixes: ff0c4346fc ('core: add rate-limiting helper')
Sending and receiving RA is repeated periodically. Don't spam logs
with the same message again and again. Rate limit the message to 6
every 12 hours per type and per ndisc instance.
Using nm_device_create_l3_config_data_from_connection in favor of
nm_l3_config_data_new_from_connection allows the connection
properties: connection.mdns, connection.llmnr,
connection.dns-over-tls, connection.dnssec, connection.mptcp-flags,
and ipv6.ip6-privacy to be read from the vpn's connection settings
allowing them to be applied to vpn connections.
Currently nm_device_create_l3_config_data_from_connection uses the
connection applied to the given device for some properties. Altough
this currently works since all users of
nm_device_create_l3_config_data_from_connection provide the applied
connection as parameter, it behaves unexpectedly when another
connection is given.
This is needed to ensure that the right CleanupType is chosen when
calling to nm_device_state_changed() a bit later. With this change
CLEANUP_TYPE_REMOVED will be used instead of CLEANUP_TYPE_DECONFIGURE,
which is wrong because the device has already disappeared.
As we introduced the ipv4.forwarding property in a8a2e6d727 ('ip-config:
Support configuring per-device IPv4 sysctl forwarding option'), we must
not enable or disable the global forwarding setting in the kernel, as it
affects to all the devices, maybe forcing them to behave in a way
different to what the user requested in ipv4.forwarding.
Instead, we need to selectively enable or disable the per-device forwarding
settings. Specifically, only devices activated with ipv4.forwarding=auto
must have their forwarding enabled or disabled depending on shared
connections. Devices with yes/no must not be affected by shared connections.
Also, devices with ipv4.forwarding=auto must get the proper forwarding value
on activation, but also change it when shared connections appear or
disappear dynamically. Use the new sharing-ipv4-change signal from
nm_manager to achieve it.
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
This signal notifies about the "sharing state", that's it, when there
is at least one shared connection active or not. Each device informs
to nm_manager when a shared connection is activated or deactivated
and nm_manager emits this signal when the first shared connection is
activated or the last one is deactivated.
For now we're only interested in IPv4 forwarding as it's the only one
that we need to track from nm_device (in following commits).
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
With the ipv4.forwarding property we may modify the forwarding sysctl of
the device on activation. In next commits, we will also modify it if the
connection is shared, instead of modifying the global forwarding.
Restore the forwarding value to the default one when the device is
deconfigured for any reason.
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
This reverts commit 2ad5fbf025.
It is actually a partial revert. The changes to documentation don't need
to be reverted.
Fixes: 2ad5fbf025 ('policy: refresh IPv4 forwarding after connection activation and disconnection')
0d4dcc9bb4 n-dhcp4: introduce n_dhcp4_c_connection_clear_client_ip() helper
433c57ab2e n-dhcp4: Do not set ciaddr in DISCOVER state.
feacc2cccd n-dhcp4: change the default DSCP value to 0
b64e2c62e8 n-dhcp4: support setting the DSCP value
6cfa9d84d0 n-dhcp4: set xid of the DHCP header for RELEASE and DECLINE message
git-subtree-dir: src/n-dhcp4
git-subtree-split: 0d4dcc9bb45d5a63d53a787289ad79823343e624
Trying to resolve hosts using localhost errors out for ipv6 attempts:
$ host www.seznam.cz localhost
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
www.seznam.cz has address 77.75.77.222
www.seznam.cz has address 77.75.79.222
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
www.seznam.cz has IPv6 address 2a02:598:a::79:222
www.seznam.cz has IPv6 address 2a02:598:2::1222
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
It's because on some distros (like openSUSE), localhost is defined both
as 127.0.0.1 and ::1.
So listen on ::1 too. This makes ipv4-switchoff easier.
/etc/resolv.conf should likely be updated to contain ::1 eventually too
(see update_dns()).
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1188
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
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).
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 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 ...
