In glib_dep we specify
"-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
which is the dependency we use almost everywhere. With g-ir-scanner
this causes compiler warnings:
[xxx] Generating NM-1.0.gir with a custom command
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_object_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:252:13: warning: Not available before 2.70
252 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_fundamental_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:370:13: warning: Not available before 2.70
370 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
g-ir-scanner: link: gcc -o /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0 /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/src/NetworkManager/build/src/libnm-client-impl -Wl,-rpath,/src/NetworkManager/build/src/libnm-client-impl -lnm -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgmodule-2.0 -ludev -lgirepository-1.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0
Work around that.
Meson's gnome.generate_gir() is not very flexibly in allowing to
pass extra `--cflags-begin {} --cflags-end` parameters.
Hack around by adding a pseudo dependency that resets
these defines.
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
See-also: 1234e5583a ('build/autotools: avoid compiler warning generating "NM-1.0.gir"')
In practice there is little difference.
Previously, "strbuf" would own the string until the end of the function,
when the "nm_auto_str_buf" cleanup attribute destroys it. In the
meantime, we would pass it on to _fw_nft_call_sync(), which in fact
won't access the string after returning.
Instead, we can just transfer ownership to the GBytes instance. That seems
more logical and safer than aliasing the buffer owned by NMStrBuf with
a g_bytes_new_static(). That way, we don't add a non-obvious restriction
on the lifetime of the string. The lifetime is now guarded by the GBytes
instance, which, could be referenced and kept alive longer.
There is also no runtime/memory overhead in doing this.
On rhel-8.7, we are going to no longer use the pre-generated docs, but
instead generate them on build time with "gtk-doc-1.28-4.el8".
That version of gtk-doc has problems with these deprecated/available
macros on the structs, so it will generate:
/usr/share/gtk-doc/html/libnm/libnm-nm-vpn-service-plugin.html
/usr/share/gtk-doc/html/libnm/libnm-nm-vpn-plugin-old.html
instead of
/usr/share/gtk-doc/html/libnm/NMVpnServicePlugin.html
/usr/share/gtk-doc/html/libnm/NMVpnPluginOld.html
Newer gtk-doc versions don't have this problem.
But as we usually don't use these macros on typedefs (only on functions), and as
1.2 is very old already, it seems simpler to just drop this (instead of
fixing gtk-doc).
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=1995915
ASSUME is causing more troubles than benefits it provides. This patch is
dropping NM_L3_CFG_COMMIT_TYPE_ASSUME and assume_config_once. NM3LCfg
will commit as if the sys-iface-state is MANAGED.
This patch is part of the effort to remove ASSUME from NetworkManager.
After ASSUME is dropped when starting NetworkManager it will take full
control of the interface, re-configuring it. The interface will be
managed from the start instead of assumed and then managed.
This will solve the situations where an interface is half-up and then a
restart happens. When NetworkManager is back it won't add the missing
addresses (which is what assume does) so the interface will fail during
the activation and will require a full activation.
https://bugzilla.redhat.com/show_bug.cgi?id=2050216https://bugzilla.redhat.com/show_bug.cgi?id=2077605https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1196
The order of addresses matters. For "ipv4.addresses", the list
contains the primary address first. For "ipv6.addresses", the
order was reverted. This was also documented behavior.
The previous patch just changed behavior with respect to relative order
of static IPv6 addresses and autoconf6/DHCPv6. As we seem in the mood
for changing behavior, here is another one.
Now the addresses are interpreted in an order consistent with IPv4 and
how one might expect: preferred addresses first.
The order of addresses can matter for source address selection.
This is described in RFC 6724 section 5, but if the rules don't
determine a clear winner, the order matters.
Change the relative order of IPv6 addresses. Previously, we would prefer
autoconf6, over DHCPv6, over manual addresses. Now that got reverted
to make more sense and be consistent with IPv4.
Also, if we had multiple autoconf6 addresses (received at different
moments in time), then previously a newly received address would be
added with highest priority. Now, the older address will be preferred
and that order will be enforced (this can be a problem, see (*) below).
For IPv4, it's all simple and sensible. When we add addresses in kernel
via netlink, the first address (of a subnet) becomes the primary.
Note that we only control the order of addresses of the same subnet.
The addresses in ipv4.addresses" are sorted with primary address first.
In the same way is the order for addresses in NML3ConfigData and for
@known_addresses in nm_platform_ip_address_sync(), all primary-first.
Also, manual addresses are sorted with higher priority compared to DHCPv4
addresses (at least since NetworkManager 1.36). That means the way how we
merge NML3ConfigData makes sense (nm_l3_config_data_merge()) because we first
merge the static configuration, then the DHCPv4 configuration, where we just
append the lower priority DHCPv4 addresses.
For IPv6, the address priority is messed up. On netlink/kernel, the last added
address becomes the preferred one (we thus need to add them in the order of
lowest priority first). Consequently and historically, the IPv6 addresses in
@known_addresses parameter to nm_platform_ip_address_sync() were
lowest priority first. And so they were tracked in NML3ConfigData
and in the profile ("ipv6.addresses"). That is confusing.
Also, we usually want to merge NML3ConfigData with different priorities
(e.g. static configuration from the profile before autoconf6/DHCPv6),
as we do with IPv4. However, since internally IPv6 addresses are tracked in
reverse order, it means later NML3ConfigData would be appended and get effectively
a higher priority. That means, autoconf6 addresses were preferred over DHCPv6 and
over manual "ipv6.addresses", respectively. That seems undesirable and inconsistent
with IPv4. Change that. This is a change in behavior.
Note that changing the order of addresses means to remove and re-add
them in the right (inverse) order, with lease important first. This
means, when we add a new address with lower priority, we need to remove
all higher priority addresses temporarily, before readding them. That
is a problem(*).
Note that in the profile, "ipv6.addresses" is still tracked in reverse
order. This did not change, but might change later.
When attaching a bond port, kernel will reset the MTU of the port ([1],
[2]). Configuring a different MTU on the port seems not a sensible
thing for the user to do.
Still, before commit e67ddd826f ('device: commit MTU during stage2')
we would first attach the bond port before setting the MTU. That
changed, and now the MTU set by kernel wins.
Btw, this change in behavior happens because we attach the port in
stage3 (ip-config), which seems an ugly thing to do.
Anyway, fix this by setting the MTU after attaching the ports, but still
in stage3.
It is probably not sensible for the user to configure a different MTU.
Still, if the user requested it by configuration, we should apply it.
Note that NetworkManager has some logic to constrain the MTU based on
the parent/child and controller/port. In many regards however, NetworkManager
does not fully understand or enforce the correct MTU and relies on the
user to configure it correctly. After all, if the user misconfigures the
MTU, the setup will have problems anyway (and in many cases neither
kernel nor NetworkManager could know that the configuration is wrong).
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/bonding/bond_main.c?h=v5.17#n3603
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/bonding/bond_main.c?h=v5.17#n4372https://bugzilla.redhat.com/show_bug.cgi?id=2071985
Fixes: e67ddd826f ('device: commit MTU during stage2')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1199
On glibc, HOST_NAME_MAX is defined as 64. Also, Linux'
sethostname() enforces that limit (__NEW_UTS_LEN). Also,
`man gethostname` comments that HOST_NAME_MAX on Linux is
64.
However, when building against musl, HOST_NAME_MAX is defined as 255.
That seems wrong. We use this limit to validate the hostname, and that
should not depend on the libc or on the compilation.
Hardcode the value to 64.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1197
The source file now contains UTF-8 (non ASCII) characters. Python2
doesn't like that:
"./src/tests/client/test-client.sh" "." "." "/usr/bin/python"
File "/builddir/build/BUILD/NetworkManager-1.39.2/src/tests/client/test-client.py", line 1730
SyntaxError: Non-ASCII character '\xe2' in file /builddir/build/BUILD/NetworkManager-1.39.2/src/tests/client/test-client.py on line 1730, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
Fixes this error:
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
./configure: line 30294: ,as_fn_error: command not found
checking for a Python interpreter with version >= 3... python
checking for python... /usr/bin/python
Fixes: 3affccf29b ('tests: fix undefined references to pthread')
nm_hostname_is_valid() determines the valid length based on
HOST_NAME_MAX, which is defined differently for glibc and musl.
Fixes: 9ff1f66680 ('glib-aux: add nm_hostname_is_valid() helper from systemd')
This test calls "nmcli g" with a bogus D-Bus bus address. We expect
a failure on stderr.
On alpine:latest, the error however looks slightly different:
b'size: 258\nlocation: src/tests/client/test-client.py:test_offline()/1\ncmd: $NMCLI g\nlang: C\nreturncode: 1\nstderr: 136 bytes\n>>>\nError: Could not create NMClient object: Key/Value pair 0, *invalid*, in address element *very:invalid* does not contain an equal sign.\n\n<<<\n'
On ubuntu:16.04 and debian:9 we got:
b"size: 258\nlocation: src/tests/client/test-client.py:test_offline()/1\ncmd: $NMCLI g\nlang: C\nreturncode: 1\nstderr: 136 bytes\n>>>\nError: Could not create NMClient object: Key/Value pair 0, 'invalid', in address element 'very:invalid' does not contain an equal sign.\n\n<<<\n"
On fedora and most recent systemd we got:
b'size: 258\nlocation: src/tests/client/test-client.py:test_offline()/1\ncmd: $NMCLI g\nlang: C\nreturncode: 1\nstderr: 136 bytes\n>>>\nError: Could not create NMClient object: Key/Value pair 0, ?invalid?, in address element ?very:invalid? does not contain an equal sign.\n\n<<<\n'
This depends on the glib version (whether to print `%s', '%s', or “%s”).
Also, as we run the application with lang=C, so that libc (I think)
replaces Unicode with an ASCII character. Here musl and glibc behave
differently.
Workaround by replace the unexpected text.
Let the replace_arr parameter of Util.replace_text() only contain
callables, and don't special case the argument. Previously, we
either expected a regex or a 2-tuple, and the code would check
each explicitly.
Aside that the tuples are hard to follow, it also makes
Util.replace_text() strongly tied to those types. By instead accepting
and arbitrary function, each element can implement its own replacement.
Also, make text that was replaced by regex atomic. Meaning, if we
first match (and replace) a certain part of the text with the regex,
then the replacement cannot be split again. This is done by returning
a 1-tuple from the replace function.
This was only for unit testing, to check whether our reader
for "/etc/machine-id" agrees with systemd's.
That unit test was anyway flawed, because it actually accesses
the machine-id on the test system.
Anyway. Drop this. Most likely our parser is good enough, and
if we get a bug report with a defect, we can unit test against
that.
We use these functions, currently from our systemd fork. One day we want
to stop importing systemd code, so we need them ourselves.
Copy them, and adjust for NM style.
This seams easier to read. And as we have a unit test that covers all
possible 256 input values, it's easy to refactor and ensure the code
still works.
Seems the previous code did not work properly:
With python36-3.6.8-38.module+el8.5.0+12207+5c5719bc.x86_6 on rhel-8.6:
Traceback (most recent call last):
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 1157, in f
func(self)
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 1724, in test_offline
replace_stdout=replace_uuids,
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 797, in call_nmcli
frame,
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 997, in _call_nmcli
self.async_start(wait_all=sync_barrier)
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 1032, in async_start
async_job.wait_and_complete()
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 670, in wait_and_complete
self._complete_cb(self, return_code, stdout, stderr)
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 919, in complete_cb
stdout = Util.replace_text(stdout, replace_stdout)
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 362, in replace_text
if Util.is_regex_pattern(v_search):
File "/root/nm-build/NetworkManager/src/tests/client/test-client.py", line 208, in is_regex_pattern
t = re.Pattern
AttributeError: module 're' has no attribute 'Pattern'
On this python version, re.compile() give an object of type
_sre.SRE_Pattern.
# python -c 'import re; print(type(re.compile("a")))'
<class '_sre.SRE_Pattern'>
Fixes: beebde9e56 ('client/test: allow matching and replacing regex-es in nmcli output')
