These checks don't seem very useful, to have them enabled
in production code.
What is actually the real danger of messing up with binary search,
is that the input array is not properly sorted. Asserting for that
would be way more useful, but also likely too expensive to be worth
it.
Checking that the input arguments are not NULL/zero, is not that useful,
because we "usually" won't make such mistakes.
While at it, declare each local variable on a separate line.
For connections with multi-connect property set to "multiple", the
autoconnect-retries should be tracked per device and not per connection.
That means, if autoconnect-retries is set to 2, each device using that
connection should retry to autoconnect 2 times.
The device autoconnect retries is -2 by default. This is a special
value, in NMPolicy context, if the connection used is multi-connect the
device value will be set to match the connection retries. Each time the
device picks a different connection, it will reset the device
autoconnect retries to -2 and if needed, sync. with the connection
retries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1387https://bugzilla.redhat.com/show_bug.cgi?id=2039734
This partly reverts 1fe8166fc9 ('device: only deactivate when the master
we've enslaved to goes away').
If the controller fails while the port is not yet fully attached,
before this patch the following happened:
<info> [1664299566.1065] device (bond0): state change: ip-config -> failed (reason 'config-failed', sys-iface-state: 'managed')
...
<warn> [1664299566.1073] device (bond0): Activation: failed for connection 'bond0'
<trace> [1664299566.1073] device[6b76ac7314eb0b53] (bond0): master: release one slave a9f10ea824bb1725/eth1 (not enslaved) (configure)
<debug> [1664299566.1073] device[a9f10ea824bb1725] (eth1): unmanaged: flags set to [!sleeping,!by-type,!platform-init,!user-explicit,!user-settings,!user-conf=0x0/0x179/managed], forget [is-slave=0x800], reason removed)
...
<info> [1664299566.1080] device (eth1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Note that now eth1 has no controller, but it lingers in "ip-config" state indefinitely.
If we look at a case where the port is already attached we see:
<info> [1664299540.9661] device (bond0): state change: secondaries -> failed (reason 'config-failed', sys-iface-state: 'managed')
...
<warn> [1664299540.9667] device (bond0): Activation: failed for connection 'bond0'
<trace> [1664299540.9667] device[6b76ac7314eb0b53] (bond0): master: release one slave a9f10ea824bb1725/eth1 (enslaved) (configure)
<debug> [1664299540.9667] platform: (eth1) link: releasing 10 from master 'bond0' (80)
...
<info> [1664299540.9740] device (bond0): detached bond port eth1
...
<debug> [1664299540.9749] device[a9f10ea824bb1725] (eth1): Activation: connection 'eth1' master failed
...
<warn> [1664299540.9749] device (eth1): queue-state[secondaries, reason:none, id:520]: replace previously queued state change
...
<debug> [1664299540.9750] device[a9f10ea824bb1725] (eth1): queue-state[deactivating, reason:dependency-failed, id:533]: queue state change
<debug> [1664299540.9751] device[a9f10ea824bb1725] (eth1): unmanaged: flags set to [!sleeping,!by-type,!platform-init,!user-explicit,!user-settings,!user-conf=0x0/0x179/managed], forget [is-slave=0x800], reason removed)
...
<debug> [1664299541.0201] device[a9f10ea824bb1725] (eth1): enslaved to unknown device 0 (??)
...
<debug> [1664299541.0227] device[a9f10ea824bb1725] (eth1): queue-state[deactivating, reason:dependency-failed, id:533]: change state
<info> [1664299541.0228] device (eth1): state change: ip-check -> deactivating (reason 'dependency-failed', sys-iface-state: 'managed')
Fix that by not ignoring the nm_device_slave_notify_release() call. Now we get:
<info> [1664391684.9757] device (bond0): state change: ip-config -> failed (reason 'config-failed', sys-iface-state: 'managed')
...
<debug> [1664391684.9759] active-connection[69c2b12d61f5b171]: set state deactivated (was activating)
<debug> [1664391684.9760] active-connection[142bb8240f6a696d]: check-master-ready: already signalled (state activating, master 0x56116f1480a0 is in state deactivated)
...
<debug> [1664391684.9762] manager: ActivatingConnection now (none)
...
<warn> [1664391684.9763] device (bond0): Activation: failed for connection 'bond0'
<trace> [1664391684.9763] device[142828814dec6e26] (bond0): master: release one slave 720791275fe8a68c/eth1 (not enslaved) (configure)
<debug> [1664391684.9763] device[720791275fe8a68c] (eth1): Activation: connection 'eth1' master failed
...
<debug> [1664391684.9764] device[720791275fe8a68c] (eth1): queue-state[deactivating, reason:dependency-failed, id:3047]: queue state change
<debug> [1664391684.9765] device[720791275fe8a68c] (eth1): unmanaged: flags set to [!sleeping,!by-type,!platform-init,!user-explicit,!user-settings,!user-conf=0x0/0x179/managed], forget [is-slave=0x800], reason removed)
...
<debug> [1664391684.9797] device[720791275fe8a68c] (eth1): queue-state[deactivating, reason:dependency-failed, id:3047]: change state
<info> [1664391684.9797] device (eth1): state change: config -> deactivating (reason 'dependency-failed', sys-iface-state: 'managed')
Commit 1fe8166fc9 ('device: only deactivate when the master we've
enslaved to goes away') added the "return", but it seems to also add it
in cases where we need to handle this. Restrict the return to cases if
we do "no-config".
https://bugzilla.redhat.com/show_bug.cgi?id=2130287
Fixes: 1fe8166fc9 ('device: only deactivate when the master we've enslaved to goes away')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1406
The G_TYPE_INSTANCE_GET_CLASS() macro is just one pointer dereference
(self)->g_class, plus additional assertions with debug builds.
As such, it is as fast as it gets. Embed the address family there, and
implement NM_SETTING_IP_CONFIG_GET_ADDR_FAMILY() that way.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1395
NMConnection is an interface, implemented by NMSimpleConnection and
NMRemoteConnection.
For the most part, an NMConnection is only the content of the profile
(the settings). The "path" of the connection refers to the D-Bus path,
and wouldn't really make sense of the NMConnection interface or the
NMSimpleConnection type.
As such, the daemon (which only uses NMConnection and
NMSimpleConnection) never sets the path. Only libnm does.
NMClient uses NMRefString extensively for the D-Bus interface and the
path is already internalized. Take advantage of that. It is very likely,
that we are able to share the path instance in libnm at which point it
makes sense to use NMRefString.
Also, during nm_simple_connection_new_clone(), we can just take another
reference instead of cloning the string.
"nm-setting-ip-config.c" is a base class for IPv4 and IPv6 settings. So
far, any tags there were ignored, which was not obvious. It can be
useful to document common properties there. Well, maybe every property
better has a IPv4/IPv6 specific text, but that should not be a technical
limitation of the tool. So also honor the base file for "ipv4" and
"ipv6" settings.
When doing that, the settings are no longer processed in the order as
they are provided on the command line. Because, one file would be parsed
twice, it wouldn't make much sense. Instead, sort the my setting name.
The advantage is that the generated XML is independent from the order
that make/meson passes to the tool.
If the information is missing, the entire attribute should not be there.
Don't set it to the empty word.
Also, don't alias the "variable" attribute to the "name". It's not clear
what the "variable" fields is supposed to mean, but if it's not
explicitly set, don't make up the information. If a user of that
information cares, the can always fallback to the "name".
Our docs can be long. It's important to be able to express paragraphs.
Honor a blank line to include a newline. For XML often whitespace is
ignored, but our tools can choose to honor the newline.
Also, don't strip the whitespace from the beginning and the end.
We keep whitespace for a certain indentation level, but additional
whitespace gets preserved. This is less important, because regular
spaces is indeed irrelevant. But when we write the annotations, we
should be in full control over spaces.
With the given input, this produces *exactly* the same XML as before.
- the parsing is now stricter (and thus the code more verbose). No
funny stuff, get the annotations correct.
- on parsing errors, we log now the affecting lines
- "nm-setting-ip-config.c" is a base class. Previously it was ignored
and for the moment we still do that. Next, we will allow to also
describe properties there.
- prepare the code to better preserve whitespace, indentation and line
wrappings. In particular, to honor a blank line to indicate a line break
and support paragraphs. This is not yet done to compare the output
to before, but will be turned on with a small patch next.
- the code will make it simple to promote the XML attributes to
nodes. Attributes aren't great, let's write XML nodes later.
We will only need to adjust the "keywords" dictionary for that,
but this change will require changes to the entire chain of tools.
Before:
$ nmcli device connect veth0; echo $?
Error: Connection activation failed: (5) IP configuration could not be reserved (no available address, timeout, etc.).
0
After
$ nmcli device connect veth0; echo $?
Error: Connection activation failed: (5) IP configuration could not be reserved (no available address, timeout, etc.).
4
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/902
For new uses of nm_uuid_generate_from_strings() we should generate version5
UUIDs and we should use unique namespace UUID arguments.
The namespace UUID was so far replaced by always passing a special prefix
as first string. It seems nicer to use a namespace instead.
Version3 UUIDs should not be used for new applications.
Hence, nm_uuid_generate_from_strings_v3() is no longer a desirable way to
generate UUIDs, so drop the wrapper.
Some snake oil, but this is a low level function and we don't know
whether the caller doesn't try to hash secret information. Just clear
the buffer after use.
nm_uuid_generate_from_strings() accepts a uuid_type and type_arg
parameter, so that we can use it to generate version 5 UUIDs.
This is a more flexible variant of nm_uuid_generate_from_strings_v3(),
which will be used to replace it. With the right parameters, the new
function behaves the same as nm_uuid_generate_from_strings_v3().
nm_uuid_generate_from_strings() uses variant3 UUIDs based on MD5.
We shouldn't use that in the future.
We will add a replacement, so rename this function so that the "good"
name is free again. Of course, code that uses this function currently
relies on that the behavior doesn't change. We cannot just drop it
entirely, but will replace it by something that gives the same result.
Rename.
`NM_UUID_INIT(00, 09, 01, ...)` would look as if the values are
octal numbers. That is not the case. The macro mangles them,
so that the look like the UUID in string form "000901...".
This is a bit odd. Maybe more confusing than helpful. Or maybe helpful?
We already redefine those checks to optimize for NMSimpleConnection.
Which, in particular when libnm-core is used by the daemon, is the only
implementation of the NMConnection interface.
Move those to the private header file. No need to keep it private to
"nm-connection.c".
NMConnection is an interface, and as such has no data itself.
In practice, there are only two implementations of this interface,
NMSimpleConnection and NMRemoteConnection. The latter only exists
in libnm, not the daemon.
Thus, lookup of the private data is already optimized for
NMSimpleConnection instances via _nm_simple_connection_private_offset.
Use the same mechanism also for NMSimpleConnection itself.
Instead, hack gettext's Makefile.
gettext has an issue with parallel make. See [1] and [2].
Reproduce with:
git reset --hard &&
git clean -fdx &&
NOCONFIGURE=yes ./autogen.sh &&
./configure --enable-gtk-doc --enable-introspection &&
make -j distcheck V=1
We worked around this by setting "DIST_DEPENDS_ON_UPDATE_PO = yes",
however that (obviously) results in regenerating source files during
dist. "Source files" in the sense that the po files are commited to git
and get distributed in the release. Doing this is very ugly.
In particular it's ugly, because `make -C po update-po` is not reproducible
and the output depends on the current time (*had one job*).
Otherwise, we could just regenerate the files before doing a release.
This means, running "release.sh" script ends up with a dirty tree
afterwards. Also, the distributed po files are not the ones from the source
tree when we did the release. Also, since "release.sh rc1" does two distributions
(once for the rc1 and once for the next devel snapshot), the commit for the
second distribution will have a large diff for the po files.
This reverts commit 978d8eb699 ('po: make dist depend on update-po')
and hacks around the problem.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1094#note_1435313
[2] https://lists.gnu.org/archive/html/bug-gettext/2022-06/msg00022.htmlhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1405
Our GObject structs should be internal API. In which case, we should
embed the private data in the struct themselves (`_priv`) and use the
_NM_GET_PRIVATE() macro. The advantage is better debugability because
following G_TYPE_INSTANCE_GET_PRIVATE() in the debugger is very
cumbersome. Another (less relevant) advantage is better performance.
Thus, warn about uses of g_type_class_add_private() and
G_TYPE_INSTANCE_GET_PRIVATE().
Note that if the struct and is in a header file (which is usually only
necessary when subclassing the type), then the private data should be
an opaque pointer `_priv` instead, and we should use the _NM_GET_PRIVATE_PTR()
macro. In that case, the use of g_type_class_add_private() and
G_TYPE_INSTANCE_GET_PRIVATE() is correct and the warning is false. But
this is only a warning, for the unusual case where we have deep object
hierarchies.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1396
It seems uncommon that a command line tool warns about duplicate
paramters. Usually, the latter just overwrites the former. That is also
useful so that you can have for example an alias that sets a default
type
nmcli_import="nmcli connection import type keyfile"
but still call it like
nmcli_import file $FILE type openvpn
This is a change in behavior. Not only stop we printing a warning, we
will now prefer the latter argument. Previously, the first was honored.
This change in behavior is a problem, but such uses were warned against
in the past, and hopefully nobody did this or relied on this.
