With --color=auto, coloring is enabled based on the .enable/.disable
termcolors files.
Likewise, when we enable coloring, we parse the color palette from the
.schem termcolors files.
The termcolors files are searched by finding the best match depending
on the terminal and application name. Note, that if we find a matching
file like "nmcli@xterm.enable" we still allow loading the palette from
a less specific file like "nmcli.schem" and vice versa. That was already
done before.
Previously, the search was done by calling several layers of functions, and having
in/out arguments "color_option" and "p_palette_buffer". in/out paramters
here seems confusing to me, as they are state that gets modified and carried
along.
Instead, rework the functions to clearly separate between input
and output arguments.
Also, in the auto-case, check_colors() now first determines whether
coloring is enabled, before even starting loading the palette.
This avoids loading the palette until we are sure that we need it.
The NmCli variables is essentially a global variable of *everything*.
The set_color() function and its helpers only need a particular
part of it. Instead, of passing the entire global state to them,
only pass what they need.
It makes it clearer which parts are actually relevant. Turns out,
it only actually touches a resonable small part of the global state.
They are known to be racy and occasionally break. Especially in
cases where the system's CPU is busy, like during parallel
`make check -j`.
It's likely a bug in libnm-glib. libnm-glib is deprecated, and the
library didn't significantly change now for several releases.
Let's not invest effort into finding bugs in the deprecated library,
bugs that are known to exist. Also, at this point, larger rework
of libnm-glib is not going to happen anymore.
Retry the test up to 5 times, trying to workaround the test failures.
'num_grat_arp' and 'num_unsol_na' are actually the same attribute on
kernel side, so if only 'num_grat_arp' is set in configuration, we
first write its value and then overwrite it with the 'num_unsol_na'
default value (1). Instead, just write one of the two option.
https://bugzilla.redhat.com/show_bug.cgi?id=1591734
A configuration with duplicate tc qdiscs and tfilters is not valid;
reject it in verify(). Note that nm_setting_tc_config_add_qdisc() and
nm_setting_tc_config_add_tfilter() can't add duplicate entries and so
the only way to achieve an invalid configuration is setting the
properties directly.
https://github.com/NetworkManager/NetworkManager/pull/95
Internally, the device migth have negative or zero ifindex.
When calling nm_manager_get_device_by_ifindex(), the caller
wants to find a device with a valid ifindex, hence filter
out non-positive values.
<error> level is for something really bad happening. When another party
(iwd in this case) sends a D-Bus request that we cannot meaningfully handle,
that is hardly reason to warn about. <debug> level is enough in this case.
Also, give all messages a common prefix "agent-request" so that we have
something to grep for.
nm_utils_random_bytes() will always try its best to give some
random numbers. A failure only means, that the kernel interfaces
get_random() or /dev/urandom failed to provide good randomness. We
don't really need good random numbers here, so no need to handle
a failure.
priv->system_secrets may be updated by e.g.
nm_settings_connection_new_secrets and nm_settings_connection_update,
but if the plugin creates the object with g_object_new, then adds some
settings but never adds any secrets there's no reason to call either of
those two methods. A call to nm_settings_connection_get_secrets should
still be able to request new secrets (and may then update
priv->system_secrets as a result).
If the hints parameter to the agent request wasn't empty, ask
specifically for the 802-1x keys listed in the hints and skip the
guessing. I didn't add human readable names for all of the 802-1x
settings, it could be useful to do for at least the three 802-1x
properties that add_8021x_secrets already knows about because
those may have translations.
Allow the IWD backend to use secrets provided in the connection settings
on initial connection attempt, only require new secrets on subsequent
connections when IWD asks for them -- it only asks if fresh secrets are
required.
The IWD DBus interface currently
(https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/doc/agent-api.txt?id=38952813dddd776f66d2ed5e88eca9a892964c06)
knows about 3 secret types related to 802.1x authentication in addition
to the PSK secret request. Add support for the new methods and the new
secret types in NM's implementation of the IWD secret agent. Note that
the secret types are mapped to NMSetting8021x property keys and they are
then sent to the NM Secret Agent in the hints parameter to GetSecrets,
this will need support in the NM clients as the exact usage of the
hints parameter is specified a little ambiguously, but this seems to be
one of the permitted usages.
Rework the IWD agent interface info initialization to use NM convenience
macros.
To improve the code logic and reduce space for bugs, don't save the
dbus invocation object as priv->secrets_request, instead move it to
the nm_act_request_get_secrets()'s user_data as we only need the
invocation object for exactly the life time of the request. See
https://github.com/NetworkManager/NetworkManager/pull/139 for
discussion.
- in wake_on_wlan_restore(), if we decide that there is something
to restore, also clear priv->wowlan_restore by setting it to
IGNORE. That way, we are sure to only try resetting the value
once after setting it.
- from nm_platform_wifi_get_wake_on_wlan(), return IGNORE if
the value cannot be read. If we could not read the value
we should not restore NONE, but don't restore.
If commit_mtu() is called multiple times and dev->get_configured_mtu()
returns @is_user_config=FALSE, only the first call changes the
MTU. So, for example, when the parent MTU of a VLAN changes, we apply
the new MTU only the first time.
Rework the handling of MTU in NMDevice, and store the source of the
configured MTU. When commit_mtu() is called again, we ask the subclass
a MTU to configure and apply it only if the source has higher
priority, or when the parent MTU changed.
Instead of returning a boolean @is_user_config value from
get_configured_mtu(), return an mtu-source enum with possible values
NONE,CONNECTION. This enum will be expanded later; for now there is no
change in behavior.
If a device-factory wouldn't support any link-type or setting-type,
we would not take an additional reference to the @factory instance
(because, the factory is not added to one of the static hash tables).
As such, we would invoke the callback with a factory instance, which
is about to be destroyed immediately afterwards. That would be unusual
for device-plugins, because usually a device-plugin is never destroyed
and essentially leaked at exit.
Just don't get into that situation. All device plugins are internal API,
and they are known to support at least something. Assert for that.
Internal device plugins are compiled-in. In fact, none of the
internal device plugins can currently be disabled via compile
time options. The user would have to patch the sources to
not include a particular device plugin.
Hence, the available device plugins depends exclusively on the
build itself. That is not worth <info> level logging. Especially,
as it was quite verbose, logging 13 lines.
Otherwise, we easily get a failure
test:ERROR:src/platform/tests/test-cleanup.c:78:test_cleanup_internal: assertion failed (addresses6->len == 2): (1 == 2)
Avoid that by waiting for kernel to add the link-local
address.
Option to check just in NM private dhcp client specific lease files has
been dropped: either get DUID from specific DHCP plugin or just use the
provided one.
This reverts commit f054c3fcaa.
On m68k architecture, the struct
typedef struct {
gint64 timestamp_ms;
bool dirty;
} IP6RoutesTemporaryNotAvailableData;
ends up being of a previously unhandled size. Causing a compile time
assertion to fail.
Support argument sizes of 10 bytes for nm_g_slice_free_fcn().
It's useless and redundant noise.
The original motivation seems to have been compatibility with ancient
versions uClibc (2011), but given CLOCK_BOOTTIME definition is shipped with
kernel headers, the libc version shall not matter anyway.
Even if it was the case, uClibc has shipped the definition for over
7 years now and been superseded by uClibc-ng that always had the
definition.
