None of the callers really handle the return value of nm_platform_ip_address_sync()
or whether the function encountered problems. What would they anyway do
about that?
For IPv4 we were already ignoring errors to add addresses, but for IPv6 we
aborted. That seems wrong. As the caller does not really handle errors,
I think we should follow through and add all addresses in case of error.
Still, also collect a overall "success" of the function and return it.
In the past, nm_platform_ip_address_sync() only had the @known_addresses
argument. We would figure out which addresses to delete and which to preserve,
based on what addresses were known. That means, @known_addresses must have contained
all the addresses we wanted to preserve, even the external ones. That approach
was inherently racy.
Instead, nowadays we have the addresses we want to configure (@known_addresses)
and the addresses we want to delete (@prune_addresses). This started to change in
commit dadfc3abd5 ('platform: allow injecting the list of addresses to prune'),
but only commit 58287cbcc0 ('core: rework IP configuration in NetworkManager using
layer 3 configuration') actually changed to pass separate @prune_addresses argument.
However, the order of IP addresses matters and there is no sensible kernel API
to configure the order (short of adding them in the right order), we still need
to look at all the addresses, check their order, and possibly delete some.
That is, we need to handle addresses we want to delete (@prune_addresses)
but still look at all addresses in platform (@plat_addresses) to check
their order.
Now, first handle @prune_addresses. That's simple. These are just the
addresses we want to delete. Second, get the list of all addresses in
platform (@plat_addresses) and check the order.
Note that if there is an external address that interferes with our
desired order, we will leave it untouched. Thus, such external addresses
might prevent us from getting the order as desired. But that's just
how it is. Don't add addresses outside of NetworkManager to avoid that.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
No need to try further. The verdict is clear.
From the log:
<debug> [1649424031.1507] connectivity: (wlan0,IPv4,427) can't resolve a name via systemd-resolved: GDBus.Error:org.freedesktop.resolve1.NoNameServers: No appropriate name servers or networks for name found
<debug> [1649424031.1507] connectivity: (wlan0,IPv4,427) start request to 'http://fedoraproject.org/static/hotspot.txt' (try resolving 'fedoraproject.org' using system resolver)
This can lead to a crash. The code might continue to call
system_resolver_resolve(), then it has no more cancellable.
That means, if the task gets cancelled, then the callback
will still return and result in a crash.
There is no need to cancel or clear the cancellable during
normal operation. It will be cleaned up at the end.
This leads to an assertion error (or possibly crash):
...
#6 0x00005584ff461e67 in system_resolver_resolve_cb (source_object=<optimized out>, res=0x5585016b9190, user_data=user_data@entry=0x558501667800) at src/core/nm-connectivity.c:798
#7 0x00007f348a02419a in g_task_return_now (task=0x5585016b9190) at ../gio/gtask.c:1219
#8 0x00007f348a0241dd in complete_in_idle_cb (task=task@entry=0x5585016b9190) at ../gio/gtask.c:1233
#9 0x00007f3489e263eb in g_idle_dispatch (source=0x7f3464001070, callback=0x7f348a0241d0 <complete_in_idle_cb>, user_data=0x5585016b9190) at ../glib/gmain.c:5897
...
Fixes: 57d226d3f0 ('connectivity: resolve hostname ourselves to avoid blocking libcurl')
We passed on the CFLAGS, but they also contain
"-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
which causes compiler warnings:
GISCAN src/libnm-client-impl/NM-1.0.gir
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c: In function ‘dump_object_type’:
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c:251:13: warning: Not available before 2.70
251 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c: In function ‘dump_fundamental_type’:
/data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c:369:13: warning: Not available before 2.70
369 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
Filter them out.
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
With "rc1" mode, we install more than one tarballs (the one for 1.37.90
and 1.39.0). If we reach this point, we already pushed the git tags.
There is no way back.
Ignore errors at first and try to release all tarballs. Only signal the error
at the end.
Supplicant does not allow setting certain properties to empty values.
It also does not make sense.
Also, ifcfg-rh writer uses svSetValueStr() for these properties, so
the ifcfg plugin would always loose having hte values set to "".
Also, you couldn't enter these strings in nmcli.
It's fair to assume that it makes no sense to have these values set to
an empty value. Since we cannot just tighten up verification to reject
them, normalize them.
It also seems that some GUI now starts setting domain_suffix_match to an
empty string. Or maybe it was always doing it, and ifcfg plugin just hid
the problem? Anyway, we have users out there who set these properties to
"".
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/973
"find-backports" script parses the commit messages to figure out which
patches to backport. We use "refs/notes/bugs" notes to extend the
meta data after the commit was merged. If you don't setup the
notes, the output is likely incomplete or wrong.
Yes, this is annoying. It requires you to setup the notes as described
in "CONTRIBUTING.md". Also because the "release.sh" script runs "find-backports",
so that means you cannot do releases without setting up the notes
(unless you manually disable running "find-backports"). But you really shouldn't
make a release based on incomplete information.
Currently NetworkManager fails to establish a NAP bridge because it never gets
out of the stage2.
This is caused because when making the BlueZ callback reentrant we return
NM_ACT_STAGE_RETURN_POSTPONE even after registration has succeeded.
This patch changes registration to a three state automaton instead of a
boolean. This allows distinguishing when we are waiting for registration
to finish and when it is done and therefore ensures that when the stage2
is called again by the callback the result is success so NetworkManager
can proceed to the IP configuration.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1181
When the ovs-bridge datapath is netdev, OpenvSwitch will not create a
ovs-interface but a tun interface. The ovs-interface device must check
all the link-change signals and check if the link type is tun and the
interface name is the same than the device name. If so, the
ovs-interface device will get the ifindex of the tun device. This allow
NetworkManager to manage the interface properly, modifying MTU,
configuring IPv4/IPv6 and others.
Example:
```
55: ovsbridge-port0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether fa:fb:07:98:e0:c6 brd ff:ff:ff:ff:ff:ff
inet 192.168.123.100/24 brd 192.168.123.255 scope global noprefixroute ovsbridge-port0
valid_lft forever preferred_lft forever
inet6 fe80::9805:55c4:4c5f:da1c/64 scope link noprefixroute
valid_lft forever preferred_lft forever
```
https://bugzilla.redhat.com/show_bug.cgi?id=2001792https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1179
"Ignore-Backport:" is already in use. For the find-backports script it
has the same meaning as a "cherry picked from" line, that means, we
assume that the referenced patch was backported already and the fix
applied.
This is of course useful to make the script shut up about backports that
we don't want to do. However, it requires us to tag the old branch
with this, so that the script thinks that the patch is already there.
Imaging we have a wrong commit on "next" branch with a Fixes line. We
don't want to backport it, so we would have to tag the "old" branch with
"Ignore-Backport:". That is cumbersome.
Instead, now also support that if a commit contains a "Fixes:" line any
an "Ignore-Fixes:" for the same fixed commit, then this let's the
"Fixes:" line be ignored.
For regular operation -- even for `level=TRACE` -- it's just too verbose.
Only enable it if the environment "NM_LOG_CONCHECK=1" is set.
An environment variable is a bit unwieldy to use, but this
is really just for a heavy libcurl debugging session.
We have some reports of APs that advertise WPA2/WPA3 with
MFP-required=0/MFP-capable=0, and reject the association when the
client doesn't support 802.11w.
According to WPA3_Specification_v3.0 section 2.3, when operating in
WPA3-Personal transition mode a STA:
- should allow AKM suite selector: 00-0F-AC:6 (WPA-PSK-SHA256) to be
selected for an association;
- shall negotiate PMF when associating to an AP using SAE.
The first is guaranteed by capability PMF; the second by checking that
the interface supports BIP ciphers suitable for PMF.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/964https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
Move initialization of NMSettingBridge from NMPlatformLnkBridge to separate
function.
This is needed because this initialization will be used in more than one
function.
We store the timestamp when a profile activated the last time to
"/var/lib/NetworkManager/timestamps". There was also a timer which
would update the timestamp of activated connections every 300 seconds.
That seems unnecessary, drop it.
For one, waking up every 5 minutes and rewriting a file to disk seems
undesirable, for example if /var is a device where unnecessary writes
should be minimized.
Note that we already update the timestamp when a device goes down,
and of course when it comes up. Updating the timestamp in between seems
unnecessary.
This reverts commit 607350294d ('core: update timestamp in active
system connections every 5 mins (bgo #583756)').
An alternative would be to only update the timestamp in memory (so that
it would appear updated on D-Bus), but delay writing the file until
something important happens. `nm_key_file_db_*()` already tracks whether
there are changes ("dirty") and whether it's necessary to write the
file. It would be possible to track two dirty flags: one that requires
immediate update, and one that only ensures we will re-write dirty files
eventually.
See-also: https://bugzilla.gnome.org/show_bug.cgi?id=583756https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1171
Previously, autotools would detect whether we have "black"
in the path. And if so, it would check formatting during `make check`.
That's problematic. When I run `./contrib/fedora/rpm/build_clean.sh -w test`
in certain cases, it would pick up black, but then fail with
Traceback (most recent call last):
File "/usr/bin/black", line 5, in <module>
from black import patched_main
File "/usr/lib/python3.6/site-packages/black.py", line 42, in <module>
from attr import dataclass, evolve, Factory
ModuleNotFoundError: No module named 'attr'
make[3]: *** [Makefile:21658: check-python-black] Error 1
That's an installation error of black, but still, during package build
there is no need to check the formatting. We could export
`NMTST_SKIP_PYTHON_BLACK=1` to prevent it, but it's still unnecessary.
We check proper formatting in gitlab-ci. That is enough, it doesn't
need to run during `make check`. In particular, because `black .`
takes 1.5 seconds on my machine.
This is more for completeness, to go along "nm-code-format.sh"
script.
Usually it's very simple to run black directly (you may still do that).
However, black by default only reformats files with ".py" extension.
So to get all our python files, you'd need to know and explicitly
select them... or use this script.
Also, `black .` scans the entire source tree, and is rather slow.
This script knows which files to select and is thus faster.
