| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
RHEL7 supports clock_gettime(CLOCK_BOOTIME), but it does not support
timerfd_create(CLOCK_BOOTIME). Fallback to CLOCK_MONOTONIC.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The autoconnection for virtual devices currently works in two
phases. First we detect that there is suitable profile that can
autoconnect and we realize the device. Then, when the device becomes
'disconnected', autoconnect kicks in and starts the activation.
However, if autoconnect is blocked for a device, currently we do step
1 without step 2, leaving a stale interface around. Fix this by also
checking that autoconnect is not blocked during step 1.
https://bugzilla.redhat.com/show_bug.cgi?id=1765047
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/360
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assertions will fail in ip_config_merge_and_apply() if the device
doesn't have an ifindex. Reproducible with:
$ nmcli connection add type ovs-bridge ifname ovs0 ipv4.method disabled ipv6.method disabled
Connection 'ovs-bridge-ovs0' (1d5e794b-10ad-4b2b-aa7c-5ca7e34b0a55) successfully added
$ nmcli device reapply ovs0
Error: Reapplying connection to device '(null)' (/org/freedesktop/NetworkManager/Devices/16) failed: Remote peer disconnected
$ journalctl -u NetworkManager -e
...
NetworkManager[73824]: nm_ip4_config_add_dependent_routes: assertion 'ifindex > 0' failed
systemd[1]: NetworkManager.service: Main process exited, code=dumped, status=5/TRAP
...
|
| |
|
|
|
|
|
|
|
| |
When the link becomes available, check that the device is in the
ip-config state before starting ip configuration. Also, reset the
'waiting_for_interface' flag when the device deactivates.
https://bugzilla.redhat.com/show_bug.cgi?id=1781165
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/358
|
| |
|
|
|
|
| |
The abbreviations "ns" and "ms" seem not very clear to me. Spell them
out to nsec/msec. Also, in parts we already used the longer abbreviations,
so it wasn't consistent.
|
| |
|
|
|
| |
I think "ms" as abbreviation is too short and unclear. Also, it's
not used consistently. Rename variable.
|
| |
|
|
|
|
|
|
|
|
| |
See mesonbuild issue 5003.
Oddly, this isn't inside a method call, while we use ternaries
inside a method calls otherwise. Anyway, workaround this and
avoid the crash.
Fixes: c21c6bc0be2a ('build/meson: allow configuring default for main.auth-polkit setting')
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With glib 2.63.2 and clang 9.0.0 (Fedora 32) we get compile errors:
../clients/cloud-setup/nmcs-provider-ec2.c:51:8: error: incompatible pointer types passing 'typeof ((((void *)0))) *' (aka 'void **') to parameter of type 'const char **' [-Werror,-Wincompatible-pointer-types]
if (!g_atomic_pointer_compare_and_exchange (&base_cached, NULL, base))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:192:44: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
__atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
^~~~~~~~~~~~~~
../src/devices/bluetooth/nm-bluez-manager.c:2836:2: error: incompatible pointer types passing 'typeof ((((void *)0))) *' (aka 'void **') to parameter of type 'const NMBtVTableNetworkServer **' (aka 'const struct _NMBtVTableNetworkServer **') [-Werror,-Wincompatible-pointer-types]
g_atomic_pointer_compare_and_exchange (&nm_bt_vtable_network_server, NULL, &priv->vtable_network_server);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:192:44: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
__atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
^~~~~~~~~~~~~~
../src/devices/bluetooth/nm-bluez-manager.c:2853:2: error: passing 'typeof ((&priv->vtable_network_server)) *' (aka 'struct _NMBtVTableNetworkServer **') to parameter of type 'const NMBtVTableNetworkServer **' (aka 'const struct _NMBtVTableNetworkServer **') discards qualifiers in nested pointer types [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
g_atomic_pointer_compare_and_exchange (&nm_bt_vtable_network_server, &priv->vtable_network_server, NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:192:44: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
__atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
^~~~~~~~~~~~~~
../src/devices/nm-device.c:8857:8: error: incompatible pointer types passing 'typeof ((((void *)0))) *' (aka 'void **') to parameter of type 'GBytes **' (aka 'struct _GBytes **') [-Werror,-Wincompatible-pointer-types]
if (!g_atomic_pointer_compare_and_exchange (&global_duid, NULL, p)) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:192:44: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
__atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
^~~~~~~~~~~~~~
The issue happens because glib passes the "atomic" argument to
__atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST)
without cast, and clang 9 seems to be picky about const pointers.
Add our own version of the macro that does better casts while also having
better compile time checks for valid arguments.
|
| |\ |
|
| | |
| |
| |
| | |
`nmcli con show`
|
| | |
| |
| |
| |
| |
| |
| | |
This will be necessary to sort a list of text that contains text to
replace. The use case is to get all UUIDs from the server, but some
of these UUIDs are dynamic. So, in order to have a fixed sort order,
we need to handle sorting the list, based on the replacement.
|
| | |
| |
| |
| | |
Will be used to get all connection from the test stub server.
|
| | |
| |
| |
| |
| |
| |
| | |
We want to issue a nmcli command with the connection's UUID in the command
line. As the command line is stored to disk and compared, we cannot use UUIDs
that are randomly generated. Instead, we need to support replacing the text
in the command line.
|
| | |
| |
| |
| |
| |
| |
| | |
TestNmcli
It had no bad effect, but the cmd was a tuple with one string, and not
a string.
|
| | | |
|
| |/
|
|
|
|
| |
The variable name should say what it is, not what it is used for.
E.g. we would use the very same replacements for stderr. Rename
so that it can (by its name) used for different purposes.
|
| |
|
|
|
|
|
|
|
|
| |
Otherwise sendfile() fails with EINVAL when the file offset
is greater than zero (pos + size > max), always on the second
iteration.
Fixes: 0c6cd07ec81d ('nm-manager: remove lease file if copying dhclient lease fails')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/359
|
| |
|
|
|
|
|
|
| |
If a device is being autoactivated and requires a parent that is
blocked due to user request, the autoactivation attempt should fail
because NM shouldn't overrule the user decision.
https://bugzilla.redhat.com/show_bug.cgi?id=1765566
|
| |\
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1779162
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/356
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Many device types take the MTU value from the wired setting; usually
they don't implement the can_reapply_change() method and so the MTU
can't be changed with the Reapply() API.
Instead of implementing the method for all such devices to support the
same property (adding a lot of duplicated code), add a check in
NMDevice to allow the reapply of MTU when we recognize that the device
uses the MTU from the wired setting.
Device types can still decide to implement can_reapply_change() and
support whatever properties they want, even from the wired setting.
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1762011
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/357
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
wrong configuration
No additional warnings are implemented yet.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
function
The underlying GPtrArray that we use to construct the list of warnings
is more useful than the strv array. For the internal function, don't
let it return the strv array but instead take (and fill) the warnings
as GPtrArray. There is no difference in practice, because also
previously we would always create an empty GPtrArray.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We always build with PolicyKit support enabled, because it has no
additional dependencies, beside some D-Bus calls.
However, in NetworkManager.conf the user could configure
"main.auth-polkit" to disable PolicyKit. However, previously it would
only allow to disable PolicyKit while granting access to all users.
I think it's useful to have an option that disables PolicyKit and grants
access only to root. I think we should not go too far in implementing
our own authorization mechanisms beside PolicyKit (e.g. you cannot
disable PolicyKit and grant access based on group membership of the
user). However, disabling PolicyKit can be useful sometimes, and it's
simple to implement a "root-only" setup.
Note one change is that when NetworkManager now runs without a D-Bus
connection (in initrd), it would deny all non-root requests. Previously
it would grant access. I think there should be little difference in
practice, because if we have no D-Bus we also don't have any requests to
authenticate.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
We always build PolicyKit support, because it merely depends on some
D-Bus calls. However, there are two things to configure:
- the default value for main.auth-polkit in NetworkManager.conf. This
is now called "-Dconfig_auth_polkit_default=$VAL".
- whether to install the policy file. This is called "-Dpolkit=$VAL".
These settings are mostly independent, so add "config_auth_polkit_default" to
make the default explicitly configurable.
|
| |
|
|
| |
- also use nm_auto_close and nm_close().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When moving a lease file from initramfs directory to NetworkManager
run directory, SELinux label for that file retains tmpfs_t type.
Fix it by using sendfile() instead of rename(). That way, the
lease file will have the default type: NetworkManager_var_run_t.
Since we take ownership of the lease file, also drop it from the
old location.
* Before the patch:
ls -Z /var/run/NetworkManager/dhclient-*.lease
system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease
* After:
ls -Z /var/run/NetworkManager/dhclient-*.lease
system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease
Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, other applications cannot bind to port 0.0.0.0:68 at the same time.
This is for example what dhclient wants to do. So even when running
dhclient on another, unrelated interface, it would fail to bind the UDP
socket and quit.
Note that also systemd-networkd's DHCPv4 client sets this socket option.
Presumably for the same reasons.
Signed-off-by: Thomas Haller <thaller@redhat.com>
https://github.com/nettools/n-dhcp4/pull/12
|
| |
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1745574
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLMNR and mDNS settings can have their global default value configured
in "NetworkManager.conf".
Global default values should work the way that all regular values of the property
can be configured explicitly in the connection profile. The special "default" value
only indicates to allow lookup of the global default, but it should not have a
meaning of its own.
Note that if mDNS/LLMNR settings are left unspecified, we will set the
argument to SetLinkMulticastDNS() and SetLinkLLMNR() functions to "",
which means that systemd-resolved decides on a default. Also, depending
on the DNS plugin, the default value differs. This is all fine however.
In this case, the ultimate default value depends on other things (like
the DNS plugin), but each possible value is in fact explicitly
configurable. We also do that for "ipv6.ip6-privacy".
Anyway, cleanup the documentation a bit and try to better explain what
the default is.
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/355
|
| | |
| |
| |
| | |
This affects nmtui and nm-cloud-setup, which use nmc_client_new_waitsync().
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids unnecessarily fetching permissions, which are not needed
most of the time.
During `nmcli general permissions` we require to fetch the permissions. This is
now solved better, because previously the code waited for any permissions to be
not UNKNOWN. That was a hack, because there are cases where all permissions would
be UNKNOWN (hidepid mount option) and nmcli would hang.
There is a downside too: for `nmcli general permissions` we now first
need to wait for NMClient to initialize, before starting to fetch
permissions. Previously, we would call GetPermissions() in parallel
with initializing NMClient. It now takes longer.
That should be fixed be refactoring the code in nmcli to not wait for
NMClient to be fully initialized, before requesting the permissions.
|
| | |
| |
| |
| |
| | |
This will allow us to set construct parameters to the instance, like
NM_CLIENT_INSTANCE_FLAGS.
|
| | |
| |
| |
| | |
nm-online doesn't care about the permissions. Don't fetch them.
|
| | |
| |
| |
| |
| | |
This will allow us to set construct parameters to the instance, like
NM_CLIENT_INSTANCE_FLAGS.
|
| | |
| |
| |
| | |
nm-cloud-setup doesn't care about the permissions. Don't fetch them.
|
| | | |
|
| | |
| |
| |
| | |
nmtui doesn't care about the permissions. Don't fetch them.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Using sync init (nm_client_new()) has an overhead as it requires an internal
GMainContext to ensure preserving the order of D-Bus messages. Let's avoid
that by using the async init. Note that the difference here is that we will
iterate the caller's GMainContext while creating the instance. But that
is no problem for nmtui at that point.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Benefits:
- nmc_client_new_async*() allows to set properties on the NMClient
instance before calling g_async_initable_init_async().
It also allows to subscribe to any signals (like NM_CLIENT_DEVICE_ADDED)
before actually iterating the GMainContext. This is a sensible and
supported thing to do!
- nmc_client_new_waitsync() iterates the GMainContext until the (async)
initialization is complete. That is different from synchronous nm_client_new(),
which does not iterate the caller's GMainContext, and hence needs an
internal context to ensure the order of events is honored.
- nmc_client_new_waitsync() always returns the NMClient instance, even
if initialization fails.
That is useful if you need the nm_client_get_context_busy_watcher() instance
to ensure all pending messages are completed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have "shared/nm-libnm-core-aux", which is shared code that can be used
by anybody (including libnm-core, src, libnm and clients).
We have "clients/common", which are helper function for clients. But
that implies that the code is inside "clients". I think it would be
useful to have auxiliary code that extends libnm, but is not only
usable by code in "clients". In other words, "shared/nm-libnm-aux"
is a better place than "clients/common", and I think most of the
functionality form "clients/common" should move there.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
"shared/nm-glib-aux/tests"
"shared/nm-utils" got long renamed and split into separate parts. The remaining
tests are really to test nm-std-aux and nm-glib-aux (no libnm dependencies). Move
the tests to the appropriate place.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, NMClient by default always fetches the permissions
("GetPermissions()") and refreshes them on "CheckPermissions" signal.
Fetching permissions is relatively expensive, while they are not used
most of the time. Allow the user to opt out of this.
For that, have a NMClientInstanceFlags to enable/disable automatic
fetching. Also add a "permissions-state" property that allows the user
to understand whether the cached permissions are up to date or not.
This is a bit an awkward API for handling this. E.g. you cannot
explicitly request permissions, you can just enable/disable fetching
permissions. And then you can watch the permission-state to know whether
you are ready. It's done this way because it fits the previous model
and extends the API with a (relative) small amount of new functions and
properties.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a flags property to control behavior of NMClient.
Possible future use cases:
- currently it would always automatically fetch permissions. Often that
is not used and the user could opt out of it.
- currently, using sync init creates an internal GMainContext. This
has an overhead and may be undesirable. We could implement another
"sync" initialization that would merely iterate the callers mainloop
until the initialization completes. A flag would allow to opt in.
- currently, NMClient always fetches all connection settings
automatically. Via a flag the user could opt out of that.
Instead NMClient could provide an API so the user can request
settings as they are needed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On D-Bus, the permission names are just the PolicyKit action names, like
"org.freedesktop.NetworkManager.wifi.scan". But NMClient already
ignores all strings that it doesn't know at compile time and only
keeps track of well known permission.
And neither does the API nm_client_get_permissions_result() allow to
expose permissions unknown to libnm.
Maybe the API of NMClient should be more generic and allow exposing
any permissions announced by NetworkManager. As it is however, it's
not necessary to track the permissions in a hash table. An array with
fixed indices is sufficient.
|
| | | |
|
