Otherwise, gcc-14.0.1-0.2.fc40 warns:
../src/libnm-core-impl/nm-utils.c: In function _nm_utils_strstrdictkey_create:
../src/libnm-core-impl/nm-utils.c:5076:16: error: allocation of insufficient size '1' for type 'NMUtilsStrStrDictKey' {aka 'struct _NMUtilsStrStrDictKey'} with size '2' [-Werror=alloc-size]
5076 | return g_malloc0(1);
| ^~~~~~~~~~~~
(cherry picked from commit 63ab0d926d)
gcc-14.0.1-0.2.fc40 warns:
CC src/libnm-core-impl/libnm_core_impl_la-nm-setting-team.lo
../src/libnm-core-impl/nm-setting-team.c: In function nm_team_link_watcher_new_ethtool:
../src/libnm-core-impl/nm-setting-team.c:127:13: error: allocation of insufficient size 16 for type NMTeamLinkWatcher with size 48 [-Werror=alloc-size]
127 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^
(cherry picked from commit 5715feebe7)
Section 4.9 of RFC 4594 specifies that DHCP should use the standard
(CS0 = 0) service class. Section 3.2 says that class CS6 is for
"transmitting packets between network devices (routers) that require
control (routing) information to be exchanged between nodes", listing
"OSPF, BGP, ISIS, RIP" as examples of such traffic. Furthermore, it
says that:
User traffic is not allowed to use this service class. By user
traffic, we mean packet flows that originate from user-controlled
end points that are connected to the network.
Indeed, we got reports of some Cisco switches dropping DHCP packets
because of the CS6 marking.
For these reasons, change the default value to the recommended one,
CS0.
(cherry picked from commit d8b33e2a97)
Currently the internal DHCP client sets traffic class "CS6" in the DS
field of the IP header for outgoing packets.
dhclient sets the field according to the definition of TOS (RFC 1349),
which was was deprecated in 1998 by RFC 2474 in favor of DSCP.
Introduce a new property IPvX.dhcp-dscp (currently valid only for
IPv4) to specify a custom DSCP value for DHCP backends that support it
(currently, only the internal one).
Define the default value to CS0, because:
- section 4.9 of RFC 4594 specifies that DHCP should use the standard
(CS0 = 0) service class;
- section 3.2 says that class CS6 is for "transmitting packets
between network devices (routers) that require control (routing)
information to be exchanged between nodes", listing "OSPF, BGP,
ISIS, RIP" as examples of such traffic. Furthermore, it says that:
User traffic is not allowed to use this service class. By user
traffic, we mean packet flows that originate from user-controlled
end points that are connected to the network.
- we got reports of some Cisco switches dropping DHCP packets because
of the CS6 marking.
(cherry picked from commit fcd907e062)
The client currently always sets the DSCP value in the DS field
(formerly known as "TOS") to CS6. Some network equipment drops packets
with such DSCP value; provide a way to change it.
(cherry picked from commit 2f543f1154)
Previously, input fields for peer attributes such as 'Public Key' were
not pre-populated with the existing settings of the peer. This was due
to the WireGuard peer editor class not setting its peer property during
object construction, as the necessary flag was absent. This commit
addresses and fixes this issue.
Closes#1443https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1851
(cherry picked from commit 7e7d3a7981)
To embrace inclusive language, deprecate the NMSettingConnection
autoconnect-slaves property and introduce autoconnect-ports property.
(cherry picked from commit 194455660d)
In order to make _nm_setting_property_define_direct_enum more flexible,
this patch is introducing property_type argument to it. When set to NULL
it will set property_type to nm_sett_info_propert_type_direct_enum.
(cherry picked from commit b90dd247be)
Defining the wrong from_dbus/to_dbus functions is something not
probable. The unit test is just getting in the way of those who knows
what they do and force contributors to change the same thing in multiple
places.
(cherry picked from commit 2f1b599fe3)
OpenShift MetalLB team requests to configure additional routes
whenever the nodes does not have a configured IP address or route for
the subnet in which MetalLB issues addresses.
Note in linux network stack, it does not matter what interface you add
the address on a node (for example, loopback), the kernel is always
processing arp-requests and sending arp-replies to any of them, this
behavior is considered correct and, moreover, it is widely used in the a
dynamic environment as Kubernetes.
https://issues.redhat.com/browse/RHEL-5098https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/1587
The decision to configure or not configure routes without addresses only
related to what method is configured - DHCP and non-DHCP cases. For DHCP
case, the deamon waits until addresses appear first before configuring
the static routes to preserve the behavior mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=2102212, otherwise, the
daemon can configure the routes immediately for non-DHCP case.
"nm_setting_hsr_get_port1" is new API and verify() already enforces that
the strings are not empty. The flag is redundant.
Also drop it from a few other places, where it's redundant.
Most properties don't accept empty strings and reject them during
verify().
All _nm_setting_property_define_direct_mac_address() call
nm_utils_hwaddr_valid() on the string, which rejects empty strings.
Clear the .direct_string_allow_empty flag for those. The usage of the
flag is misleading.
Most string properties should not accept empty strings. Add a generic
way to reject them during verify.
Add a new flag NMSettInfoProperty.direct_string_allow_empty.
Note that properties must opt-in to allow empty values. Since all
existing properties didn't have this check (but hopefully re-implemented
it in verify()), all existing properties get this flag set to TRUE.
The main point here it that new properties get the strict check by
default.
We should also review existing uses of direct_string_allow_empty,
whether the flag can be cleared. This can be done if verify() already
enforces a non-empty string, or if we accept to break behavior by
tightening up the check.
Current verifications happens by implementing NMSetting's verify().
Add code for a second step of validation, that can operate based on the
known type.
The use case will be to reject empty strings.
To embrace inclusive language, deprecate the NMSettingConnection
slave-type property and introduce port-type property.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
The `ustar` format that is used to generate NM tarballs only supports
a 21-bit uid/gid causing the `make dist` command (or similar commands involving
tar archive creation) fails for users with high UIDs. This commit
changes the tar format from `ustar` to `pax` format which does not have such
limitation and is aligned with future plan to switch to meson
build system (which already uses the `pax` format).
When deleting a profile, the confirmation dialog shows "Cancel" and
"Delete" buttons. ESC key should do nothing, but in some distributions
like Debian and Ubuntu newt has a downstream patch that enables it (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584098).
In that case, when pressing ESC the return value of the dialog is not
"Cancel" (1) or "Delete" (2), but the "otherwise" value (0). Fix it by
not checking if "Cancel" is pressed. Instead, check if "Delete" was
pressed, and continue deleting only in that case.
Also, fix the doc comment that incorrectly says that the dialog returns
0/1 for the buttons, it is 1/2.
If a generated connection matches a connection that uses interface name
as controller, we need to drop the existing value from the settings to
avoid conflicts. Therefore, both of them need to be dropped; controller
and master.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1833
Fixes: 3e4a2ebb3c ('all: use the new NMSettingConnection Controller property')
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Previously, the tarball generated by `meson dist` did not contain the
autogenerated documentation due to the way meson works (packaging the
latest revision control commit). This introduces a dist script which
builds & copies the generated documentation into the distribution
tarball.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1811
Mark the methods/properties deprecated in the D-Bus API (via
org.freedesktop.DBus.Introspectable.Introspect(), [1]).
It affects those properties that are documented as deprecated in
introspection XML.
$ busctl -j call \
org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.DBus.Introspectable \
Introspect | \
jq '.data[0]' -r | \
grep -5 Deprecated
[1] https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable
Note that some of those sandboxing options may require relatively
recent systemd. In that case, to run against older systemd, you
will need to patch the service file. I don't think there is
a way around that, and limiting outselves to only the oldest supported
option is harmful for users who run recent systemd.
See-also: https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening
A IPv4 conflict detected during the probe is a serious problem, as it
prevents the address from being configured. As such, is should be
displayed at warning level.
A conflict detected after the address is already configured
(addr_info->state == NM_L3_ACD_ADDR_STATE_CONFLICT) is less important
because NM will try to defend the address and will keep using it.
A duplicate address is a serious issue which leads to non-working
setups or problems hard to debug. Enable IPv4 duplicate address
detection (aka ACD, RFC 5227) by default to detect such problems.
While the RFC recommends a timeout of 9 seconds, a comment in n-acd
sources says:
A 9s timeout for successful link setups is not acceptable today.
Hence, we will just go forward and ignore the proposed values. On
both wired and wireless local links round-trip latencies of below
3ms are common. We require the caller to set a timeout multiplier,
where 1 corresponds to a total probe time between 0.5 ms and 1.0
ms. On modern networks a multiplier of about 100 should be a
reasonable default. To comply with the RFC select a multiplier of
9000.
Set a default timeout of 200ms, which is the double of the value
suggested in n-acd sources. 200ms sounds quick enough, and gives at
least ~100ms to other hosts to reply.
See also the Fedora change proposal:
https://fedoraproject.org/wiki/Changes/Enable_IPv4_Address_Conflict_Detection
