$ nmcli connection add type dummy con-name x autoconnect no ipv4.method disabled ipv6.method disabled ifname d0
$ ip link add d1 type dummy
$ nmcli connection up x ifname d1
Error: device 'd1' not compatible with connection 'x': The interface names of the device and the connection didn't match..
$ nmcli connection add type dummy con-name x autoconnect no ipv4.method disabled ipv6.method disabled ifname d0
$ mcli connection up x ifname bogus
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/12)
This is not right. A non-existing ifname argument was simply ignored
and nmcli would tell NetworkManager to activate the profile (on any
device).
Instead, if the user specifies a device argument, also for a virtual
type, it must exist.
Note that usually for virtual devices (like 'dummy'), the device
in fact does not exist, so passing `ifname` is likely to fail.
If the device already exists, then the command is no going to work
as expected, with
$ mcli connection up x ifname d0
succeeding, while
$ mcli connection up x ifname d1
fails (as intended) with
Error: device 'd1' not compatible with connection 'x': The interface names of the device and the connection didn't match..
$ nmcli connection add type ethernet con-name x autoconnect no ipv4.method disabled ipv6.method disabled
$ nmcli connection up x ifname bogus
Error: device 'bogus' not compatible with connection 'x'.
Better would be:
Error: device 'bogus' not found for connection 'x'.
Let the default normalization from nm_connection_normalize() choose
'ipv6.method'. It will now choose "disabled" for dummy profiles, which
is just what we need.
In particular, we don't want to enable autoconf for dummy devices --
unless the profile which the user provides already has it enabled (in
which case nm_connection_normalize() doesn't change it).
$ ip link add dd type dummy
$ nmcli device
DEVICE TYPE STATE CONNECTION
...
dd dummy unmanaged --
$ nmcli device connect dd
Error: Failed to add/activate new connection: A 'dummy' setting is required.
There are two problems here. The first is that we don't pass
the interface name to nm_utils_complete_generic(), but dummy
devices require "connection.interface-name" set. As a consequence,
nm_utils_complete_generic() fails to normalize the connection
and there is no [dummy] setting. Which then results in a failure
with complete_connection().
The important part of the fix is to set the interface name. Once
we do that, nm_utils_complete_generic() should be able to add
the [dummy] setting and the second part is not strictly necessary.
Still, the job of complete_connection() is not to verify the
profile but to create it with best effort. If a [dummy] setting
is still missing, we should just add it. The caller will then
again try to normalize/verify the connection, and that might then
fail -- but this time not with the wrong error message about
missing 'dummy' setting.
https://bugzilla.redhat.com/show_bug.cgi?id=1763054
"ipv6.method=ignore" really exists for historic reasons, from a time when
NetworkManager didn't support IPv6 autoconf and let kernel handle it.
Nowadays, we should choose an explicit mode, like "link-local" or
"disabled".
Let nm_connection_normalize() treat WireGuard and dummy profiles
different and set the IPv6 method to "disabled".
On a dummy device we cannot do DHCP. The default makes no sense.
This also affects `nmcli device connect dummy0`. We want that the
generated profile gets normalized to no IP configuration, because
DHCP/autoconf is not working on a dummy device.
Currently there is another problem and that command is not working. But
if that other problem would be fixed, then the generated profile would try
to do DHCP, fail, and retry endlessly (with backoff pauses).
That endless loop is a third problem. If `nmcli device connect` creates
a new profile, then upon failure the profile should be deleted again.
But these two other problems are not solved hereby.
I guess, to a certain point these normalization options are hardly used.
Still, it feels right to also support it for IPv4. These options make
sense to me to control normalization.
I missed that we already have a gettid() wrapper. Drop the duplicated
again and use nm_utils_gettid().
Fixes: e874c5bf6b ('random: Provide missing gettid() declaration')
Coverity warns about this:
2. NetworkManager-1.32.2/tools/generate-docs-nm-property-infos.py:117: identical_branches:
The same code is executed regardless of whether "temp.index(subelement) < len(temp) - 1" is
true, because the then and else branches are identical. Should one of the branches be modified,
or the entire 'if' statement replaced?
Fixes: c3504f7e62 ('Rewrite `./tools/generate-docs-nm-property-infos.py` with XML library')
libnm symbol 'nm_setting_ip_config_get_required_timeout' was
backported to branch 1.32 in commit 08ce20481c ('all: add a new
ipv{4,6}.required-timeout property') in anticipation of 1.32.4. Add
the same symbol version so that an application linked against 1.32.4
also works with 1.34.0. We don't need a duplicate symbol version
because 1.34 is not yet released.
If the kernel command-line doesn't contain an explict ip=$method,
currently the generator creates connections with both IPv4 and IPv6
set to 'auto', and both allowed to fail.
Since NM is run in configure-and-quit mode in the initrd, NM can get
an IPv4 address or an IPv6 one (or both) depending on which address
family is quicker to complete. This unpredictable behavior is not
present in the legacy module, which always does IPv4 only by default.
Set a required-timeout of 20 seconds for IPv4, so that NM will
preferably get an IPv4, or will fall back to IPv6.
See also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/729
Add a new property to specify the minimum time interval in
milliseconds for which dynamic IP configuration should be tried before
the connection succeeds.
This property is useful for example if both IPv4 and IPv6 are enabled
and are allowed to fail. Normally the connection succeeds as soon as
one of the two address families completes; by setting a required
timeout for e.g. IPv4, one can ensure that even if IP6 succeeds
earlier than IPv4, NetworkManager waits some time for IPv4 before the
connection becomes active.
g_rand_new() reads /dev/urandom and falls back to timestamp and pid.
At this point, we already unsuccessfully tried getrandom()/urandom,
so that doesn't seem promising to try.
Try harder to get good random seeds for our GRand instance.
Have one global instance, that gets seeded with various things that come
to mind. The random sequence of that instance is then used to initialize
the thread-local GRand instances.
Maybe this is all snake oil. If we fail to get good randomness by using
kernel API, what can we do? But really, callers also don't know how they
should handle a failure to get random data (short of abort() or
logging), so there is value in nm_utils_random_bytes() trying really
the best it can, and callers pretending that it doesn't fail.
This aims to improve the fallback case.
_nm_thread_local is very neat, but when we allocate resources
we need to make sure that they are destroyed when the thread
exits.
We can use pthread_setspecific() for that, but using it is cumbersome.
Add a helper function to make that simpler.
Also, the number of possible pthread_key_t keys is limited. With this
way, we only need one key in total.
We have two GKeyfile files (timestamps and seen-bssids).
When a profile was deleted while NetworkManager was running, then
entries were removed from these keyfiles. But if a profile disappeared
while NetworkManger was stopped, then those UUIDs piled up.
This also happens if you have temporary connections in /run and reboot.
We need a way to garbage collect entries that are no longer relevant.
As the keyfile databases only get loaded once from disk, we will prune
all UUIDs for which we have no more connection loaded, on the first time
we write out the files again.
Note what this means: if you "temporarily" remove a connection profile
(without NetworkManager noticing) and restore it later, then the additional
information might have been pruned. There is no way how NetworkManager
could know that this UUID is coming back. The alternative is what we did
before: pile them up indefinitely. That seems more problematic.
Previously, there was no limit how many seen-bssids are tracked.
That seems problematic, also because there is no API how to get
rid of an excessive list of entries.
We should limit the number of entries. Add an (arbitrary) limit
of 30.
But this means that we drop the surplus of entries, and for that it
seems important to keep the newest, most recently seen entries.
Previously, entries were merely sorted ASCIIbetically. Now, honor
their order (with most recently seen first).
Also, normalize the BSSIDs. From internal code, we should only get
normalize strings, but when we load them from disk, they might be bogus.
As we might cut of the list, we don't want that invalid entries
cut of valid ones. And of course, invalid entries make no sense at
all.
ifcfg-rh plugin never stored the seen bssid list to file, and
keyfile no longer does, and it's no longer parsed from GVariant.
So there is actually no way how anything could be set here.
The seen-bssids should only be populate from
"/var/lib/NetworkManager/seen-bssids". Nowhere else.
