| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
./src/libnm-platform/nm-platform.h:1315: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
make[2]: *** [Makefile:11063: src/core/platform/tests/test-cleanup-fake] Error 1
./src/libnm-platform/nm-platform.h:1315: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
make[2]: *** [Makefile:11070: src/core/platform/tests/test-cleanup-linux] Error 1
|
| |
|
|
|
| |
src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:1449: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
make[2]: *** [Makefile:11132: src/core/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh] Error 1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:1449: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
make[2]: *** [Makefile:11132: src/core/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh] Error 1
src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
/usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
make[2]: *** [Makefile:11049: src/core/platform/tests/test-address-fake] Error 1
src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
/usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
make[2]: *** [Makefile:11063: src/core/platform/tests/test-cleanup-fake] Error 1
src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
/usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
make[2]: *** [Makefile:11077: src/core/platform/tests/test-link-fake] Error 1
src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
/usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
make[2]: *** [Makefile:11105: src/core/platform/tests/test-route-fake] Error 1
src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
/usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
make[2]: *** [Makefile:11028: src/core/ndisc/tests/test-ndisc-fake] Error 1
src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
/usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
make[2]: *** [Makefile:11187: src/core/tests/config/test-config] Error 1
|
| |
|
|
|
|
|
|
|
|
| |
/usr/bin/ld: src/libnm-core-impl/tests/test_general-test-general.o: in function `test_ip4_netmask_to_prefix':
src/libnm-core-impl/tests/test-general.c:4965: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
/usr/bin/ld: src/libnm-core-impl/tests/test-general.c:4966: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
/usr/bin/ld: src/libnm-core-impl/tests/test_general-test-general.o: in function `test_ip4_prefix_to_netmask':
src/libnm-core-impl/tests/test-general.c:4937: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
collect2: error: ld returned 1 exit status
make: *** [Makefile:11322: src/libnm-core-impl/tests/test-general] Error 1
|
| |
|
|
|
|
|
|
|
| |
/usr/bin/ld: src/core/.libs/libNetworkManager.a(libNetworkManager_la-nm-dnsmasq-utils.o): in function `nm_dnsmasq_utils_get_range':
src/core/dnsmasq/nm-dnsmasq-utils.c:53: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
/usr/bin/ld: src/core/.libs/libNetworkManager.a(libNetworkManager_la-nm-vpn-connection.o): in function `_dbus_signal_ip_config_cb':
src/core/vpn/nm-vpn-connection.c:2109: undefined reference to `nm_utils_ip4_address_clear_host_address'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:10920: src/core/NetworkManager-all-sym] Error 1
|
| |
|
|
|
|
|
| |
/usr/bin/ld: src/nmtui/nmtui-nm-editor-bindings.o: in function `ip_route_transform_from_dest_string':
src/nmtui/nm-editor-bindings.c:447: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:11644: src/nmtui/nmtui] Error 1
|
| |
|
|
|
|
|
|
| |
/usr/bin/ld: src/nm-cloud-setup/nm_cloud_setup-main.o: in function `_nmc_mangle_connection':
src/nm-cloud-setup/main.c:369: undefined reference to `nm_utils_ip4_address_clear_host_address'
/usr/bin/ld: src/nm-cloud-setup/main.c:360: undefined reference to `nm_utils_ip4_address_clear_host_address'
collect2: error: ld returned 1 exit status
make: *** [Makefile:11403: src/nm-cloud-setup/nm-cloud-setup] Error 1
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1190
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DHCP leases for a given interface are already exported on D-Bus
through DHCP4Config and DHCP6Config objects. It is useful to have the
same information also available on the filesystem so that it can be
easily used by scripts.
NM already saves some information about DHCP leases in /var, however
that directory can only be accessed by root, for good reasons.
Append lease options to the existing state file
/run/NetworkManager/devices/$ifindex. Contrary to /var this directory
is not persistent, but it seems more correct to expose the lease only
when it is active and not after it expired or after a reboot.
Since the file is in keyfile format, we add new [dhcp4] and [dhcp6]
sections; however, since some options have the same name for DHCPv4
and DHCPv6, we add a "dhcp4." or "dhcp6." prefix to make the parsing
by scripts (e.g. via "grep") easier.
The option name is the same we use on D-Bus. Since some DHCPv6 options
also have a "dhcp6_" prefix, the key name can contain "dhcp6" twice.
The new sections look like this:
[dhcp4]
dhcp4.broadcast_address=172.25.1.255
dhcp4.dhcp_lease_time=120
dhcp4.dhcp_server_identifier=172.25.1.4
dhcp4.domain_name_servers=172.25.1.4
dhcp4.domain_search=example.com
dhcp4.expiry=1641214444
dhcp4.ip_address=172.25.1.182
dhcp4.next_server=172.25.1.4
dhcp4.routers=172.25.1.4
dhcp4.subnet_mask=255.255.255.0
[dhcp6]
dhcp6.dhcp6_name_servers=fd01::1
dhcp6.dhcp6_ntp_servers=ntp.example.com
dhcp6.ip6_address=fd01::1aa
|
| | |
| |
| |
| |
| | |
Introduce a function to return an array of name-value tuples for DHCP
options.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix wrong domain when logging a lease:
dhcp6 (veth0): valid_lft 7200
dhcp6 (veth0): preferred_lft 5400
dhcp6 (veth0): address fd00:db8:db8::11:2233:4455
dhcp (veth0): domain search 'domain'
|
| |/
|
|
|
|
| |
Instead of logging the event-id, which is composed from options that
are already visible in the log, it's more interesting to log that the
lease was merged.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In glib_dep we specify
"-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
which is the dependency we use almost everywhere. With g-ir-scanner
this causes compiler warnings:
[xxx] Generating NM-1.0.gir with a custom command
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_object_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:252:13: warning: Not available before 2.70
252 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_fundamental_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:370:13: warning: Not available before 2.70
370 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
g-ir-scanner: link: gcc -o /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0 /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/src/NetworkManager/build/src/libnm-client-impl -Wl,-rpath,/src/NetworkManager/build/src/libnm-client-impl -lnm -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgmodule-2.0 -ludev -lgirepository-1.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0
Work around that.
Meson's gnome.generate_gir() is not very flexibly in allowing to
pass extra `--cflags-begin {} --cflags-end` parameters.
Hack around by adding a pseudo dependency that resets
these defines.
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
See-also: 1234e5583a09 ('build/autotools: avoid compiler warning generating "NM-1.0.gir"')
|
| |
|
|
| |
test data
|
| |
|
|
|
| |
This is a python example. We should do nice things, like
using max() for finding the maximum, instead of sorting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In practice there is little difference.
Previously, "strbuf" would own the string until the end of the function,
when the "nm_auto_str_buf" cleanup attribute destroys it. In the
meantime, we would pass it on to _fw_nft_call_sync(), which in fact
won't access the string after returning.
Instead, we can just transfer ownership to the GBytes instance. That seems
more logical and safer than aliasing the buffer owned by NMStrBuf with
a g_bytes_new_static(). That way, we don't add a non-obvious restriction
on the lifetime of the string. The lifetime is now guarded by the GBytes
instance, which, could be referenced and kept alive longer.
There is also no runtime/memory overhead in doing this.
|
| | |
|
| |
|
|
|
| |
Get `ip netns exec` to work. Now we can start stuff in their
own namespace, which is much cleaner.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libnm headers
On rhel-8.7, we are going to no longer use the pre-generated docs, but
instead generate them on build time with "gtk-doc-1.28-4.el8".
That version of gtk-doc has problems with these deprecated/available
macros on the structs, so it will generate:
/usr/share/gtk-doc/html/libnm/libnm-nm-vpn-service-plugin.html
/usr/share/gtk-doc/html/libnm/libnm-nm-vpn-plugin-old.html
instead of
/usr/share/gtk-doc/html/libnm/NMVpnServicePlugin.html
/usr/share/gtk-doc/html/libnm/NMVpnPluginOld.html
Newer gtk-doc versions don't have this problem.
But as we usually don't use these macros on typedefs (only on functions), and as
1.2 is very old already, it seems simpler to just drop this (instead of
fixing gtk-doc).
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=1995915
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ASSUME is causing more troubles than benefits it provides. This patch is
dropping NM_L3_CFG_COMMIT_TYPE_ASSUME and assume_config_once. NM3LCfg
will commit as if the sys-iface-state is MANAGED.
This patch is part of the effort to remove ASSUME from NetworkManager.
After ASSUME is dropped when starting NetworkManager it will take full
control of the interface, re-configuring it. The interface will be
managed from the start instead of assumed and then managed.
This will solve the situations where an interface is half-up and then a
restart happens. When NetworkManager is back it won't add the missing
addresses (which is what assume does) so the interface will fail during
the activation and will require a full activation.
https://bugzilla.redhat.com/show_bug.cgi?id=2050216
https://bugzilla.redhat.com/show_bug.cgi?id=2077605
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1196
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1185
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The order of addresses matters. For "ipv4.addresses", the list
contains the primary address first. For "ipv6.addresses", the
order was reverted. This was also documented behavior.
The previous patch just changed behavior with respect to relative order
of static IPv6 addresses and autoconf6/DHCPv6. As we seem in the mood
for changing behavior, here is another one.
Now the addresses are interpreted in an order consistent with IPv4 and
how one might expect: preferred addresses first.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
autoconf6/DHCPv6
The order of addresses can matter for source address selection.
This is described in RFC 6724 section 5, but if the rules don't
determine a clear winner, the order matters.
Change the relative order of IPv6 addresses. Previously, we would prefer
autoconf6, over DHCPv6, over manual addresses. Now that got reverted
to make more sense and be consistent with IPv4.
Also, if we had multiple autoconf6 addresses (received at different
moments in time), then previously a newly received address would be
added with highest priority. Now, the older address will be preferred
and that order will be enforced (this can be a problem, see (*) below).
For IPv4, it's all simple and sensible. When we add addresses in kernel
via netlink, the first address (of a subnet) becomes the primary.
Note that we only control the order of addresses of the same subnet.
The addresses in ipv4.addresses" are sorted with primary address first.
In the same way is the order for addresses in NML3ConfigData and for
@known_addresses in nm_platform_ip_address_sync(), all primary-first.
Also, manual addresses are sorted with higher priority compared to DHCPv4
addresses (at least since NetworkManager 1.36). That means the way how we
merge NML3ConfigData makes sense (nm_l3_config_data_merge()) because we first
merge the static configuration, then the DHCPv4 configuration, where we just
append the lower priority DHCPv4 addresses.
For IPv6, the address priority is messed up. On netlink/kernel, the last added
address becomes the preferred one (we thus need to add them in the order of
lowest priority first). Consequently and historically, the IPv6 addresses in
@known_addresses parameter to nm_platform_ip_address_sync() were
lowest priority first. And so they were tracked in NML3ConfigData
and in the profile ("ipv6.addresses"). That is confusing.
Also, we usually want to merge NML3ConfigData with different priorities
(e.g. static configuration from the profile before autoconf6/DHCPv6),
as we do with IPv4. However, since internally IPv6 addresses are tracked in
reverse order, it means later NML3ConfigData would be appended and get effectively
a higher priority. That means, autoconf6 addresses were preferred over DHCPv6 and
over manual "ipv6.addresses", respectively. That seems undesirable and inconsistent
with IPv4. Change that. This is a change in behavior.
Note that changing the order of addresses means to remove and re-add
them in the right (inverse) order, with lease important first. This
means, when we add a new address with lower priority, we need to remove
all higher priority addresses temporarily, before readding them. That
is a problem(*).
Note that in the profile, "ipv6.addresses" is still tracked in reverse
order. This did not change, but might change later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When attaching a bond port, kernel will reset the MTU of the port ([1],
[2]). Configuring a different MTU on the port seems not a sensible
thing for the user to do.
Still, before commit e67ddd826fae ('device: commit MTU during stage2')
we would first attach the bond port before setting the MTU. That
changed, and now the MTU set by kernel wins.
Btw, this change in behavior happens because we attach the port in
stage3 (ip-config), which seems an ugly thing to do.
Anyway, fix this by setting the MTU after attaching the ports, but still
in stage3.
It is probably not sensible for the user to configure a different MTU.
Still, if the user requested it by configuration, we should apply it.
Note that NetworkManager has some logic to constrain the MTU based on
the parent/child and controller/port. In many regards however, NetworkManager
does not fully understand or enforce the correct MTU and relies on the
user to configure it correctly. After all, if the user misconfigures the
MTU, the setup will have problems anyway (and in many cases neither
kernel nor NetworkManager could know that the configuration is wrong).
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/bonding/bond_main.c?h=v5.17#n3603
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/bonding/bond_main.c?h=v5.17#n4372
https://bugzilla.redhat.com/show_bug.cgi?id=2071985
Fixes: e67ddd826fae ('device: commit MTU during stage2')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1199
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On glibc, HOST_NAME_MAX is defined as 64. Also, Linux'
sethostname() enforces that limit (__NEW_UTS_LEN). Also,
`man gethostname` comments that HOST_NAME_MAX on Linux is
64.
However, when building against musl, HOST_NAME_MAX is defined as 255.
That seems wrong. We use this limit to validate the hostname, and that
should not depend on the libc or on the compilation.
Hardcode the value to 64.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1197
|
| |
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1198
|
| |
|
|
|
|
|
|
|
| |
The source file now contains UTF-8 (non ASCII) characters. Python2
doesn't like that:
"./src/tests/client/test-client.sh" "." "." "/usr/bin/python"
File "/builddir/build/BUILD/NetworkManager-1.39.2/src/tests/client/test-client.py", line 1730
SyntaxError: Non-ASCII character '\xe2' in file /builddir/build/BUILD/NetworkManager-1.39.2/src/tests/client/test-client.py on line 1730, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixes this error:
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
./configure: line 30294: ,as_fn_error: command not found
checking for a Python interpreter with version >= 3... python
checking for python... /usr/bin/python
Fixes: 3affccf29b53 ('tests: fix undefined references to pthread')
|
| |
|
|
|
|
|
| |
nm_hostname_is_valid() determines the valid length based on
HOST_NAME_MAX, which is defined differently for glibc and musl.
Fixes: 9ff1f666809a ('glib-aux: add nm_hostname_is_valid() helper from systemd')
|
| | |
|
| |
|
|
|
|
| |
Util.ReplaceTextRegex
Seems to be the better name.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test calls "nmcli g" with a bogus D-Bus bus address. We expect
a failure on stderr.
On alpine:latest, the error however looks slightly different:
b'size: 258\nlocation: src/tests/client/test-client.py:test_offline()/1\ncmd: $NMCLI g\nlang: C\nreturncode: 1\nstderr: 136 bytes\n>>>\nError: Could not create NMClient object: Key/Value pair 0, *invalid*, in address element *very:invalid* does not contain an equal sign.\n\n<<<\n'
On ubuntu:16.04 and debian:9 we got:
b"size: 258\nlocation: src/tests/client/test-client.py:test_offline()/1\ncmd: $NMCLI g\nlang: C\nreturncode: 1\nstderr: 136 bytes\n>>>\nError: Could not create NMClient object: Key/Value pair 0, 'invalid', in address element 'very:invalid' does not contain an equal sign.\n\n<<<\n"
On fedora and most recent systemd we got:
b'size: 258\nlocation: src/tests/client/test-client.py:test_offline()/1\ncmd: $NMCLI g\nlang: C\nreturncode: 1\nstderr: 136 bytes\n>>>\nError: Could not create NMClient object: Key/Value pair 0, ?invalid?, in address element ?very:invalid? does not contain an equal sign.\n\n<<<\n'
This depends on the glib version (whether to print `%s', '%s', or “%s”).
Also, as we run the application with lang=C, so that libc (I think)
replaces Unicode with an ASCII character. Here musl and glibc behave
differently.
Workaround by replace the unexpected text.
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1195
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let the replace_arr parameter of Util.replace_text() only contain
callables, and don't special case the argument. Previously, we
either expected a regex or a 2-tuple, and the code would check
each explicitly.
Aside that the tuples are hard to follow, it also makes
Util.replace_text() strongly tied to those types. By instead accepting
and arbitrary function, each element can implement its own replacement.
Also, make text that was replaced by regex atomic. Meaning, if we
first match (and replace) a certain part of the text with the regex,
then the replacement cannot be split again. This is done by returning
a 1-tuple from the replace function.
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1191
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was only for unit testing, to check whether our reader
for "/etc/machine-id" agrees with systemd's.
That unit test was anyway flawed, because it actually accesses
the machine-id on the test system.
Anyway. Drop this. Most likely our parser is good enough, and
if we get a bug report with a defect, we can unit test against
that.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
They are now unused, and replaced by nm_path*() utils in glib-aux (which
are forks of the systemd code).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
We use these functions, currently from our systemd fork. One day we want
to stop importing systemd code, so we need them ourselves.
Copy them, and adjust for NM style.
|
| | |
| |
| |
| | |
They are unused now.
|
| | |
| |
| |
| | |
nm_utils_base64secret_decode()
|
| | |
| |
| |
| | |
_write_setting_wireguard()
|
| | |
| |
| |
| | |
Make the code more nm-like.
|
