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.
- replace "s_flags" field by explicit boolean fields.
- "s_msg_peek" now is simplified. Previously, we would default
to peek, unless the user caller nl_socket_disable_msg_peek()
or set nl_socket_set_msg_buf_size(). Simplify that. We now
default to peek, unless NL_SOCKET_FLAGS_DISABLE_MSG_PEEK is set.
We have no callers that call nl_socket_set_msg_buf_size(),
so we can simplify that logic and just enable peeking by default.
- keep "s_auto_ack" field, although it is always TRUE and there
is no API to toggle that. However, it is kept as a self-documenting
thing, so we would know the relevant places where auto-ack matters.
- drop nl_socket_disable_msg_peek(). We have no caller of this function
and we can set peeking in nl_socket_new(). We also don't need to
change it after creation of the socket.
The real purpose is that we set the socket options before bind().
For that, we need to be able to specify the flag during nl_socket_new().
Another reason is that these are common questions to ponder while
creating a netlink socket. There shouldn't be several setter functions,
just specify the flag right away. These parameters are not going to
change afterwards (at least, we don't need/use that and we don't have
API for that either).
We will need this, for getting nl_pktinfo control messages
that contain the extended destination group number.
Also, drop NL_SOCK_PASSCRED. It was only used to not iterate over the
control messages, but doing that should be cheap.
There really is no need for two(!) heap allocations while parsing
the netlink message. We already have it in the buffer. Just use it.
Note that netlink attributes need to be aligned to 4 bytes. But
nlmsg_next() already ensures that, so not even for alignment purpose we
need to clone the message.
Create a new "struct nl_msg_lite" that can hold pointers to everything
we need.
We almost always do the wrong thing in interactive add:
The software devices generally require an interactive name, but we don't
insist of asking for them; treating them as optional:
$ nmcli -a c add type dummy
There is 1 optional setting for General settings.
Do you want to provide it? (yes/no) [yes]
For some interface types (bridges, bonds, ...) we make up a name, presumably
for historical reasons. But we don't give the user an option to modify
them:
$ nmcli -a c add type bridge
<not asking for interface name at all>
There are 9 optional settings for Bridge device.
Do you want to provide them? (yes/no) [yes]
This fixes the above use cases -- still set the default, but be sure to
ask:
$ nmcli -a c add type dummy
Interface name:
$ nmcli -a c add type bridge
Interface name [nm-bridge1]:
Beautiful.
Do the same bookkeeping as would happen upon setting the "type" option
when the connection has a connection.type set upon its addition.
Otherwise the --ask mode is sad:
$ nmcli --ask c add connection.type team
** nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting)
Bail out! nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting)
Aborted (core dumped)
After the connection's type is set, some bookkeeping is necessary for
the interactive (--ask) mode: appropriate setting need to be added and
options enabled.
Currently it happens in an option setter; which runs when the "type"
options is present on the command line, or the value is set in a
response to interactive mode:
$ nmcli --ask c add type team
$ nmcli --ask c add
Connection type: team
But not when the property is set directly:
$ nmcli --ask c add connection.type team
** nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting)
Bail out! nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting)
Aborted (core dumped)
This doesn't fix the issue -- a followup commit (hopefully) will.
For new connections, this ensures the value in square brackets on
interactive add are always correct.
Apart from that, this allows us to initialize some non-default values
before asking (such as making up an interface name for some software
devices), and inform the user about what we picked:
Interface name [nm-bridge]:
This is slightly annoying:
$ nmcli -a c add type ethernet
There is 1 optional setting for General settings.
No point in asking if there's just one option. Just ask right away:
$ nmcli -a c add type ethernet
Interface name:
The interactive add is not too enthusiastic about not providing a value
in a list.
That is before on getting an empty line in ask_option() we take a
shortcut instead of dispatching to set_option(). That way we skip
setting the PROPERTY_INF_FLAG_DISABLED flag, causing the option to
be included in questionnaire_one_optional()'s info list.
There's no reason to avoid calling set_option() if we don't get a value;
set_option() handles NULL value just fine.
$ nmcli -a c add
Connection type: dummy
There is 1 optional setting for General settings.
Do you want to provide it? (yes/no) [yes]
Interface name [*]: lala
There are 2 optional settings for IPv4 protocol.
Do you want to provide them? (yes/no) [yes]
You can specify this option more than once. Press <Enter> when you're done.
IPv4 address (IP[/plen]) [none]:
You can specify this option more than once. Press <Enter> when you're done.
IPv4 address (IP[/plen]) [none]:
You can specify this option more than once. Press <Enter> when you're done.
IPv4 address (IP[/plen]) [none]:
...
