On RHEL-8.5, s390x with gcc-8.5.0-2.el8, we get a compiler warning:
$ CFLAGS='-O2 -Werror=maybe-uninitialized' meson build
...
cc -Isrc/libndhcp4-private.a.p -Isrc -I../src -Isubprojects/c-list/src -I../subprojects/c-list/src -Isubprojects/c-siphash/src -I../subprojects/c-siphash/src -Isubprojects/c-stdaux/src -I../subprojects/c-stdaux/src -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -g -D_GNU_SOURCE -O2 -Werror=maybe-uninitialized -fPIC -fvisibility=hidden -fno-common -MD -MQ src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o -MF src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o.d -o src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o -c ../src/n-dhcp4-c-connection.c
../src/n-dhcp4-c-connection.c: In function ‘n_dhcp4_c_connection_dispatch_io’:
../src/n-dhcp4-c-connection.c:1151:17: error: ‘type’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
uint8_t type;
^~~~
https://github.com/nettools/n-dhcp4/pull/24
nm-cloud-setup automatically detects routes, addresses and rules and configures them
on the device using the emphermal Reapply() API. That is, it does not modify the
existing profile (on disk), but changes the runtime configuration only.
As such, it used to wipe otherwise statically configured IP addresses, routes and
rules. That seems unnecessary. Let's keep the configuration from the (persistent)
configuration.
There is of course the problem that nm-cloud-setup doesn't really
understand the existing IP configuration, and it can only hope that
it can be meaningfully combined with what nm-cloud-setup wants to
configure. This should cover most simple cases, for more complex setups,
the user probably should disable nm-cloud-setup and configure the
network explicitly to their liking.
https://bugzilla.redhat.com/show_bug.cgi?id=1971527https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/893
This function is badly named, because it has no NMHostnameManager self
argument. It's just a simple function that entirely operates on a string
argument.
Move it away from "nm-hostname-manager.h" to "libnm-glib-aux/nm-shared-utils.h".
Hostname handling is complicated enough. Simple string validation
functions should not obscure the view on the complicated parts.
The numeric source IDs exist from a time before 2000, when there
was only one "GMainContext" singleton instance. Nowadays, the source
ID is only relative to one GMainContext, and you'd have to track
that association yourself. Als, g_source_remove() requires an additional
hash lookup, when you could simply track the GSource instance from the
start.
This API should not be used anymore. Operate on GSouce instances
direclty and use API like
nm_clear_g_source_inst()
nm_g_idle_add_source()
nm_g_idle_souce_new()
nm_g_source_attach()
g_source_attach
g_source_destroy
g_source_unref
etc.
Note that if you don't care about to ever remove a source again, like
scheduling an idle action that should not be cancelled, then
g_idle_add(callback, user_data);
is fine. It is only problematic to do something with those numeric IDs.
checkpatch.pl would also flag those uses, but these are just warnings
and in the few cases where such a warning is emitted wrongly, it's find
to ignore them.
Using the guint source ID always requires an additional hash lookup
during removal to find the real source instance. Use instead the
underlying GSource instance.
Searching over all sources in order to remove them is not what we want
to do. If you think you need these functions, instead keep track of the
GSource instances yourself.
I think this is non-obvious API, and should be pointed out. As we don't
really have a good place for this comment, the place is a bit unmotivated.
Still, add a comment.
We somehow need to encode an NMSettingEthtool instance that has all
options unset. Previously, that would result in no "$ETHTOOL_OPTS"
variable and thus the reader would loose a previously existing setting.
Hack it by writing a bogus
ETHTOOL_OPTS="-A $IFACE"
line.
It just seems ugly to call g_getenv() repeatedly. Environment variables
must not change (in a multi-threaded program after other threads start),
so determine the mode once and cache it.
For the umpteenth time: it is not ifcfg-rh writers decision to decide
what are valid configurations and only persist settings based on
some other settings.
If s390-options would only be allowed together with subchannels, then
this is alone nm_connection_verify()'s task to ensure.
Reproduce with
$ nmcli connection add type ethernet autoconnect no con-name zz ethernet.s390-options bridge_role=primary
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1935842
Fixes: 16bccfd672 ('core: handle s390 options more cleanly')
A failure to cancel something is not worth a warning. It probably
just means that no operation was in progress. In my logs I always
see a warning:
CODE_FILE=src/core/supplicant/nm-supplicant-interface.c
CODE_LINE=391
MESSAGE=<warn> [1624517233.8822] sup-iface[a22b181a321ffd9b,9,wlan0]: call-p2p-cancel: failed with P2P cancel failed
Downgrade this to trace level.
This is actually trying *too* hard to prevent DNS leaks, breaking normal
expected use of split DNS. Let systemd-resolved handle sending our DNS
queries to the right place instead.
It's true that NetworkManager is trying to emulate the behavior of
wg-quick here, and wg-quick uses 'resolvconf -x' to attempt to set
"exclusive" DNS. But with systemd-resolved this is implemented by
setting a ~. routing domain for the Wireguard interface. That is a
*really* big hammer already, since Domain=~. overrides +DefaultRoute,
ensuring most DNS queries can only go to other interfaces with Domain=~.
NetworkManager follows systemd-resolved's recommended convention by only
applying Domain=~. to other "privacy VPNs" since 1.26.6. Setting DNS
priority only prevents *domain-specific* "leaks", which are almost
always desired. For example, it prevents using both the Wireguard VPN
and a corporate VPN at the same time.
Note that all of the justification behind !688 applies here as well.
See-also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/688https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/585https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/901
When we are a client in the group we may be assigned an address by the
group owner. Use this address if it is available, but only if we are in
AUTO configuration mode.
`description-docbook` is the alternative tag to `description`, the
difference is that `description-docbook` expects docbook XML but not
plaintext.
Signed-off-by: Wen Liang <liangwen12year@gmail.com>
We have nm_object_get_client() property that returns a reference
to the NMClient instance. This is actually useful, because if
the function returns %NULL, it means that the object was removed
from the cache.
On the other hand, the user cannot subscribe to notifications when this
happens. Well, there are otherwise pointless signals like
NM_CLIENT_DEVICE_REMOVED, which we wouldn't need if we had a general
mechanism for NMObject instances.
Add a GObject property "client", which is just that mechanism.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/902
In NetworkManager.conf, we can only configure one "[main].dhcp="
for both address families. Consequently, NMDhcpClientFactory
represents also both address families. However, most plugins
don't support IPv4 and IPv6 together.
Thus, if a plugin does not support an address family, we fallback
to the implementation of the "internal" plugin.
Slightly rework the code how that is done. Instead of having
a "get_type()" and "get_type_per_addr_family()" callback, have
an IPv4 and IPv6 getter.
