Before 1.36, manual addresses from the profile were assigned to the
interface; restore that behavior.
The manual IP configuration also contains the DNS priority from the
profile; so this change ensures that the merged l3cd has a DNS
priority and that dynamically discovered DNS servers are not ignored
by the DNS manager.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
Improve documentation by preserving paragraphs in the
nm-settings-nmcli man pages.
To do that structure of src/libnm-client-impl/nm-settings-docs-gir.xml
was changed to have "description" as subnode to property node instead
of attribute of property node. Another subnode "description-docbook"
was added - this node is then used when generating man pages.
tools/generate-docs-nm-settings-docs-gir.py and man/nm-settings-dbus.xsl
were also changed to accomodate for changes mentioned above.
Replace xsltproc tool with python script when generating
./src/libnmc-setting/settings-docs.h.
Deleted settings-docs.xsl since it was replaced by python script.
Change src/libnmc-setting/settings-docs.h.in accodring to newly
generated src/libnmc-setting/settings-docs.h
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/661https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1260
When creating one profile for each veth during activation the creation
of the veth could fail. When the link for the first profile is created
the link for the peer is generated in kernel. Therefore when trying to
activate the second profile it will fail because the link already
exists. NetworkManager must check if the link already exists and
corresponds to the same veth, if so, it should skip the link creation.
https://bugzilla.redhat.com/show_bug.cgi?id=2036023https://bugzilla.redhat.com/show_bug.cgi?id=2105956
In initrd, a too short carrier timeout means that the machine will
possibly fail to boot. On the other hand, increasing the value doesn't
have side effects, except for a bit longer delay on some machines.
Increase the value to 10 seconds. Note that the default value is not
propagated to the real root.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1239
It was documented to be an optional parameter. That is also in line
with g_dbus_connection_call(), which is essentially wrapped by nm_client_dbus_call().
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
==30980== 8 bytes in 1 blocks are definitely lost in loss record 1,117 of 6,137
==30980== at 0x4841C38: malloc (vg_replace_malloc.c:309)
==30980== by 0x4A246C7: g_malloc (gmem.c:106)
==30980== by 0x4A4A4BB: g_variant_get_strv (gvariant.c:1607)
==30980== by 0x4A4CA73: g_variant_valist_get_nnp (gvariant.c:4901)
==30980== by 0x4A4CA73: g_variant_valist_get_leaf (gvariant.c:5058)
==30980== by 0x4A4CA73: g_variant_valist_get (gvariant.c:5239)
==30980== by 0x4A4D11D: g_variant_get_va (gvariant.c:5502)
==30980== by 0x4A4D1BD: g_variant_lookup (gvariant.c:989)
==30980== by 0xE9389: parse_capabilities (nm-supplicant-interface.c:1241)
==30980== by 0xEBF99: _properties_changed_main (nm-supplicant-interface.c:1941)
==30980== by 0xEF549: _properties_changed (nm-supplicant-interface.c:2867)
==30980== by 0xEF7ED: _get_all_main_cb (nm-supplicant-interface.c:2972)
==30980== by 0x262057: _nm_dbus_connection_call_default_cb (nm-dbus-aux.c:70)
==30980== by 0x48DB6A3: g_task_return_now (gtask.c:1215)
==30980== by 0x48DBF43: g_task_return.part.3 (gtask.c:1285)
==30980== by 0x4918885: g_dbus_connection_call_done (gdbusconnection.c:5765)
==30980== by 0x48DB6A3: g_task_return_now (gtask.c:1215)
==30980== by 0x48DB6D7: complete_in_idle_cb (gtask.c:1229)
==30980== by 0x4A20981: g_main_dispatch (gmain.c:3325)
==30980== by 0x4A20981: g_main_context_dispatch (gmain.c:4016)
==30980== by 0x4A20BEF: g_main_context_iterate.isra.23 (gmain.c:4092)
==30980== by 0x4A20E33: g_main_loop_run (gmain.c:4290)
==30980== by 0x2C5C9: main (main.c:509)
Fixes: cd1e0193ab ('supplicant: add BIP interface capability')
In the past, nmp_lookup_init_object() could both lookup all object for a
certain ifindex, and lookup all objects of a type. That fallback path
already leads to an assertion failure fora while now, so nobody should
be using this function to lookup all objects of a certain type (for
what, we have nmp_lookup_init_obj_type()).
Now, remove the fallback path, and rename the function to what it really
does.
NMPObject is a union. It's not clear to me that C guarnatees that
designated initializers will meaningfully set all fields to zero. Use
memset() instead.
It can be useful to choose a different "ipv6.addr-gen-mode". And it can be
useful to override the default for a set of profiles.
For example, in cloud or in a data center, stable-privacy might not be
the best choice. Add a mechanism to override the default via global defaults
in NetworkManager.conf:
# /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf
[connection-90-ipv6-addr-gen-mode-override]
match-device=type:ethernet
ipv6.addr-gen-mode=0
"ipv6.addr-gen-mode" is a special property, because its default depends on
the component that configures the profile.
- when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode
key means to default to "eui64".
- when configured via D-Bus, a missing addr-gen-mode property means to
default to "stable-privacy".
- libnm's ip6-config::addr-gen-mode property defaults to
"stable-privacy".
- when some tool creates a profile, they either can explicitly
set the mode, or they get the default of the underlying mechanisms
above.
- nm-initrd-generator explicitly sets "eui64" for profiles it creates.
- nmcli doesn' explicitly set it, but inherits the default form
libnm's ip6-config::addr-gen-mode.
- when NM creates a auto-default-connection for ethernet ("Wired connection 1"),
it inherits the default from libnm's ip6-config::addr-gen-mode.
Global connection defaults only take effect when the per-profile
value is set to a special default/unset value. To account for the
different cases above, we add two such special values: "default" and
"default-or-eui64". That's something we didn't do before, but it seams
useful and easy to understand.
Also, this neatly expresses the current behaviors we already have. E.g.
if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64"
is a pretty clear thing.
Note that usually we cannot change default values, in particular not for
libnm's properties. That is because we don't serialize the default
values to D-Bus/keyfile, so if we change the default, we change
behavior. Here we change from "stable-privacy" to "default" and
from "eui64" to "default-or-eui64". That means, the user only experiences
a change in behavior, if they have a ".conf" file that overrides the default.
https://bugzilla.redhat.com/show_bug.cgi?id=1743161https://bugzilla.redhat.com/show_bug.cgi?id=2082682
See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
teamdctl_connect() has a parameter cli_type. If unspecified, the
library will try usock, dbus (if enabled) and zmq (if enabled).
Trying to use the unix socket if we expect to use D-Bus can be bad. For
example, it might cause SELinux denials.
As we anyway require libteam to use D-Bus, if D-Bus is available,
explicitly select the cli type.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1255
Since kernel 5.18 there is a stricter validation [1][2] on the tos
field of routing rules, that must not include ECN bits.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f55fbb6afb8d701e3185e31e73f5ea9503a66744
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a410a0cf98854a698a519bfbeb604145da384c0e
Fixes the following failure:
>>> src/core/platform/tests/test-route-linux
>>> ...
# NetworkManager-MESSAGE: <warn> [1656321515.6604] platform-linux: do-add-rule: failure 22 (Invalid argument - Invalid dsfield (tos): ECN bits must be 0)
>>> failing... errno=-22, rule=[routing-rule,0x13d6e80,1,+alive,+visible; [6] 0: from all tos 0xff fwmark 0x4/0 suppress_prefixlen -459579276 action-214 protocol 255]
>>> existing rule: * [routing-rule,0x13d71e0,2,+alive,+visible; [6] 0: from all sport 65534 lookup 10009 suppress_prefixlen 0 none]
>>> existing rule: [routing-rule,0x13d7280,2,+alive,+visible; [4] 0: from all fwmark 0/0x9a7e9992 ipproto 255 suppress_prefixlen 0 realms 0x00000008 none protocol 71]
>>> existing rule: [routing-rule,0x13d7320,2,+alive,+visible; [6] 598928157: from all suppress_prefixlen 0 none]
>>> existing rule: [routing-rule,0x13d73c0,2,+alive,+visible; [4] 0: from 192.192.5.200/8 lookup 254 suppress_prefixlen 0 none protocol 9]
>>> existing rule: [routing-rule,0x13d7460,2,+alive,+visible; [4] 0: from all ipproto 3 suppress_prefixlen 0 realms 0xffffffff none protocol 5]
>>> existing rule: [routing-rule,0x13d7500,2,+alive,+visible; [4] 0: from all fwmark 0x1/0 lookup 254 suppress_prefixlen 0 action-124 protocol 4]
>>> existing rule: [routing-rule,0x13d75a0,2,+alive,+visible; [4] 0: from all suppress_prefixlen 0 action-109]
0: from all fwmark 0/0x9a7e9992 ipproto ipproto-255 realms 8 none proto 71
0: from 192.192.5.200/8 lookup main suppress_prefixlength 0 none proto ra
0: from all ipproto ggp realms 65535/65535 none proto 5
0: from all fwmark 0x1/0 lookup main suppress_prefixlength 0 124 proto static
0: from all 109
0: from all sport 65534 lookup 10009 suppress_prefixlength 0 none
598928157: from all none
Bail out! nm:ERROR:../src/core/platform/tests/test-route.c:1787:test_rule: assertion failed (r == 0): (-22 == 0)
Fixes: 5ae2431b0f ('platform/tests: add tests for handling policy routing rules')
This makes it more consistent with nettools' lease_to_ip4_config().
The benefit of having a self pointer, is that it provides the necessary
context for logging. Without it, these functions cannot correctly log.
At this point, it's clearer to get the necessary data directly from the
DHCP client instance, instead of having the caller passing them on
(redundantly).
For an IPv4 subnet mask we expect that all the leading bits are set (no
"holes"). But _nm_utils_ip4_netmask_to_prefix() does not enforce that,
and tries to make the best of it.
In face of a netmask with holes, normalize the mask.
We have two variants of the function: nm_utils_ip4_netmask_to_prefix()
and _nm_utils_ip4_netmask_to_prefix(). The former only exists because it
is public API in libnm. Internally, only use the latter.
nm_utils_ip4_netmask_to_prefix() and nm_utils_ip4_prefix_to_netmask()
are public API in libnm.
We thus already have an internal implementation _nm_utils_ip4_prefix_to_netmask(),
for non-libnm users. Internally, we should never use the libnm variant.
For consistency and so that we have the helper available in
libnm-glib-aux, add _nm_utils_ip4_netmask_to_prefix().
There was already an nm_assert() assertion. Upgrade this
to a g_return_val_if_fail(). This function is public API,
so this is potentially an API break. But it should highlight
a bug in the caller.
In practice, the profile probably validates, so all the
attribute names are well-known. There is thus no attribute
name that has "lock-" in the middle of the string.
Still, fix it. We want to match only at the begin of the
name.
In a logfile, the "is starting" message is an interesting point
that indicates when NetworkManager is starting. Include
also the boot-id in the log, so that we can know whether this
was a restart from the same boot.
Also drop the "for the first time" part.
<info> [1656057181.8920] NetworkManager (version 1.39.7) is starting... (after a restart, asserts:10000, boot:486b1052-4bf8-48af-8f15-f3e85c3321f6)
Setting `NM_SET_OUT(out_normalized, !is_normalized)` is correct, but looks
odd and required a long code comment.
Try to write the same code differently, I think it is easier to
read and requires less comment to explain.
