| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Just include what is actually needed.
|
| |
|
|\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/182
|
| | |
|
| |
| |
| |
| |
| |
| | |
This doesn't make any difference in practice, but it seems more correct.
It would cause issues if we decided to remove an interface from the
signal handler.
|
| |
| |
| |
| |
| |
| |
| | |
When an interface (other OVS device types can not fail) encounters an error
it indicates it by changing the error column. Watch for those changes so
that we can eventually communicate them to the OVS factory to deal with
them.
|
| | |
|
| |
| |
| |
| |
| | |
It doesn't communicate anything about the nature of the change and
indeed nothing uses it.
|
|/
|
|
|
|
|
| |
Don't crash in situations, where the bridge or a port has a child with
UUID we don't know. This could happen if we mess up the parsing of
messages from OVSDB, but could also theoretically happen in OVSDB sends
us bad data.
|
|
|
|
|
|
|
|
| |
This is to avoid updating config-extra.h timestamp very time one touches
Makefile.am, because it has a large dependency chain and makes
debugging of the Makefile inconvenient.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/180
|
|\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/172
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
property getter
Note that now the empty list will be represented as %NULL instead of an
empty strv array.
That makes no difference in pratice. The main use of this property is as
glue for NMDBusManager to expose the property on D-Bus. Thereby it uses
g_dbus_gvalue_to_gvariant() which handles %NULL just fine.
|
| |
| |
| |
| | |
"nm-settings.c" is complex enough. Move this trivial helper function to libnm-core.
|
| |
| |
| |
| |
| | |
To unlink all elements, I find a while() loop easier to read
than c_list_for_each_*safe().
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMManager and NMSettings both may have multiple authorization requests
ongoing. They need to keep track of them, at the very least to be able
to cancel them on shutdown.
Since NMAuthChain is not ref-countable, it always has only one clear
user/owner. It makes little sense otherwise. Since most callers already
want to track their NMAuthChain instances, let NMAuthChain help with that.
Embed a "parent" CList field inside NMAuthChain. This avoids requiring
an additional GSList allocation to track the element. Also, it allows to
link and append an element without iterating the list.
This ties the caller and the NMAuthChain a bit tighter together (making them
less indepdendent). Generally that is not desirable. But here it seems the
logic (of tracking the NMAuthChain) is still trivial and well separated.
It's just that NMAuthChain instances now can be linked in a CList.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
VPN settings (for openconnect) can only be handled by the keyfile settings
plugin.
In any case, such special casing belongs to the settings plugin and not
"nm-settings.c". The reason is that the settings plugin already has an
intimate understanding of the content of connections, it knows which fields
exist, their meaning, etc. It makes sense special handling of
openconnect is done there.
See also commit 304d0b869bfe ('core: openconnect migration hack').
Unfortunately it's not clear to me why/whether this is still the
right thing to do.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
connection types
nm_device_check_connection_compatible() is potentially expensive.
Check first whether the connection candidate is of a relevant type,
hoping that this check is cheaper and thus shortcuts other checks
early.
|
| |
| |
| |
| |
| |
| | |
"nm-settings.c" has more than 2000 LOC. Code that is related should be
grouped better so that it's easier to understand how it belongs
together.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMSettings is complicated enough. We should try to move independent code out
of it, so that there is only logic that is essential there.
While at it, rework how we copy the GSList items. I don't like GSList as
a data structure, but there really is no need to allocate a new list.
Just unlink the list element and prepend it in the other list.
|
| |
| |
| |
| |
| |
| |
| |
| | |
As nm_settings_plugin_initialize() could not fail (it returned no value indicating
failure), there is no reason to explicitly call this. Instead just
initialize the plugin when needed.
Also, we don't need the plugin to initialize early before nm_settings_plugin_get_connections().
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of
<info> [1558284380.2045] settings: Loaded settings plugin: SettingsPluginIfcfg ("/usr/lib64/NetworkManager/1.19.2/libnm-settings-plugin-ifcfg-rh.so")
log
<info> [1558284380.2045] settings: Loaded settings plugin: ifcfg-rh ("/usr/lib64/NetworkManager/1.19.2/libnm-settings-plugin-ifcfg-rh.so")
Note how `man NetworkManager.conf` documents "main.plugins" configuration
option where settings plugins have names like "keyfile" and "ifcfg-rh".
It's not helpful to log the GObject type name, which is an implementation
detail.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It was only kept to compare whether we loaded the same
plugin multiple times.
Note that load_plugins() already checks for duplicate plugin names,
so it actually could not happen that we tried to load the same file
more than once.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
For a "is" check, it's inconvenient to assert against the parameter
being %NULL. We should accept %NULL and just say that it's not a valid
uuid.
This relaxes previous API.
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
| |
This test keeps randomly failing. Rework is, so that we see the actual
exit status in the output of the failed test.
|
|
|
|
|
|
|
| |
Also drop the paragraph about "autoconf mechanism". The general
guideline is self evident, while it didn't mention meson builds.
Also, a first time contributor likely won't likely be concerned about
this, as this is already advanced.
|
|
|
|
| |
LGPL-2.0+ license
|
|
|
|
|
|
|
| |
Instead of adding every known option to new bond connections, only add
the ones supported by UI.
https://bugzilla.redhat.com/show_bug.cgi?id=1715720
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the mode is one of '802.3ad', 'tlb' or 'alb' and the connection has
both 'arp_interval' and 'arp_ip_target' options, during normalization
we remove 'arp_interval' because unsupported in the current mode. The
connection then becomes invalid because 'arp_ip_target' requires
'arp_interval'.
Since 'arp_interval' and 'arp_ip_target' are mutually dependent, the
latter should also be unsupported for those bonding modes.
https://bugzilla.redhat.com/show_bug.cgi?id=1718173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
@connections is NULL when doing autocompletion. Fixes the following:
$ nmcli --complete-args con monitor ""
help
id
uuid
path
filename
...
Segmentation fault (core dumped)
Fixes: 4b3297271e6f ('cli: rework connection handling for multiple results')
https://bugzilla.redhat.com/show_bug.cgi?id=1716948
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/177
|
|\
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1643841
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/129
|
| |
| |
| |
| |
| | |
Create the new setting with method=disabled if IPv6 is disabled in the
sysctl.
|
|/
|
|
|
|
|
| |
Add a new ipv6.method value 'disabled' that completely disables IPv6
for the interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1643841
|
|
|
|
|
|
| |
The values cached in the device may be stale when we start a new
activation because in a disconnected state we might have called
ip_config_merge_and_apply() which cached the main table value.
|
|
|
|
|
|
|
|
| |
Also, plan right away to backport this symbol all the way back to
1.14.8. As such, we only need to add it once, with the right linker
version "libnm_1_14_8".
But still, the symbols first appears on a major release 1.20.0.
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default value is "1", not "0". Also, because "0" is not actually a
valid value as far as teamd is concerned. This fixes:
$ nmcli connection add type team autoconnect no con-name t team.runner lacp team.runner-min-ports default
Error: Failed to add 't' connection: team.runner-min-ports: value out or range
See "teamd.conf" manual:
runner.min_ports (int)
Specifies the minimum number of ports that must be active before asserting
carrier in the master interface, value can be 1 – 255.
Default: 1
This mistake probably happend because the teamd manual is wrong in older versions [1].
[1] https://github.com/jpirko/libteam/commit/f36c191da3d65a4744582b2eb09fa297dd85f9ae
https://bugzilla.redhat.com/show_bug.cgi?id=1716987
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's rather limiting if we have no API to ask NMSettingEthtool which
options are set.
Note that currently NMSettingEthtool only supports offload features.
In the future, it should also support other options like coalesce
or ring options. Hence, this returns all option names, not only
features.
If a caller needs to know whether the name is an option name, he/she
should call nm_ethtool_optname_is_feature().
|
|\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/175
|
| |
| |
| |
| | |
git ls-files -z -- ':(exclude)src/settings/plugins/keyfile/tests/keyfiles' | xargs -0 -n1 sed -i '1 { /^$/d }'
|