summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-05-13fixup! ifcfg-rh: add support for ipv4.link-localth/pr/1187Thomas Haller2-1/+7
2022-05-12settings: ipv4.link-local global defaultThomas Haller8-491/+517
Add a "default" value, which allows to set the flag via global defaults. The default for the new property can be "default" because old uses who upgrade to a new version that supports ipv4.link-local won't have the global default configured in NetworkManager.conf. So they will always get the expected default to "auto", unless the change their configuration.
2022-05-12settings: honor ipv4.method like beforeThomas Haller7-546/+560
Rename and replace "none" flag by "auto". That means, to honor "ipv4.method", like done it the past. The upside is, that it requires no normalization. Normalization is confusing to implement, because to get it really right, we probably should support normalizing link-local based on method, but also vice versa. And since the method affects how other properties validate/normalize, it's hard to normalize that one, so that the result makes sense. Normalization is also often not great to the user, because it basically means to modify the profile based on other settings. The downside is that the auto flag becomes API and exists because we need backward compatibility with ipv4.method. We would never add this flag, if we would redesign "ipv4.method" (by replacing by per-method-specific settings).
2022-05-12ifcfg-rh: add support for ipv4.link-localAdrian Freihofer5-1/+29
2022-05-12settings: add ipv4.link-local flagAdrian Freihofer10-546/+822
Allows the ip4 local-link address configuration to be started independently of the ipv4.method configuration. This is done by adding a new link-local parameter to the ipv4 settings. The link-local parameter partially overlaps with the existing method parameter. The first step is to reject inconsistent settings for method and link-local settings.
2022-05-12libnm: merge branch 'th/libnm-infiniband-fixes'Thomas Haller1-8/+26
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1223
2022-05-12libnm: reject infiniband.p-key set to 0, 0x8000Thomas Haller1-0/+8
Kernel does not allow this ([1], [2]). Usually tightening the verification is a break of API. But in this case, no user had a working configuration that is breaking. At worst, they had a broken profile that no longer loads. We also filter those from _infiniband_add_add_or_delete(), since [3]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/infiniband/ulp/ipoib/ipoib_main.c?id=f443e374ae131c168a065ea1748feac6b2e76613#n2394 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/infiniband/ulp/ipoib/ipoib_vlan.c?id=f443e374ae131c168a065ea1748feac6b2e76613#n116 [3] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/eab817d34a38227a79b10e9c52d450bb8c7fa907
2022-05-12libnm: fix crash validating infiniband profiles for interface-nameThomas Haller1-8/+18
A virtual infiniband profile (with p-key>=0) can also contain a "connection.interface-name". But it is required to match the f"{parent}.{p-key}" format. However, such a profile can also set "mac_address" instead of "parent". In that case, the validation code was crashing. nmcli connection add type infiniband \ infiniband.p-key 6 \ infiniband.mac-address 52:54:00:86:f4:eb:aa:aa:aa:aa:52:54:00:86:f4:eb:aa:aa:aa:aa \ connection.interface-name aaaa The crash was introduced by commit 99d898cf1fa2 ('libnm: rework caching of virtual-iface-name for infiniband setting'). Previously, it would not have crashed, because we just called g_strdup_printf("%s.%04x", priv->parent, priv->p_key) with a NULL string. It would still not have validated the connection and passing NULL as string to printf is wrong. But in practice, it would have worked mostly fine for users. Fixes: 99d898cf1fa2 ('libnm: rework caching of virtual-iface-name for infiniband setting')
2022-05-12libnm: merge branch 'th/fix-libnm-includes'Thomas Haller3-61/+72
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1222
2022-05-12libnm: avoid duplicate typedefs for NMClient/NMDeviceThomas Haller2-13/+15
clang 3.4.2-9.el7 does not like this: $ clang -DHAVE_CONFIG_H -I. -I.. -I../src/libnm-core-public -I./src/libnm-core-public -I../src/libnm-client-public -I./src/libnm-client-public -pthread -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40 -Wall -Werror -Wextra -Wdeclaration-after-statement -Wfloat-equal -Wformat-nonliteral -Wformat-security -Wimplicit-function-declaration -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wundef -Wvla -Wno-duplicate-decl-specifier -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-tautological-constant-out-of-range-compare -Wno-unknown-pragmas -Wno-unused-parameter -Qunused-arguments -Wunknown-warning-option -Wtypedef-redefinition -Warray-bounds -Wparentheses-equality -Wunused-value -Wimplicit-fallthrough -fno-strict-aliasing -fdata-sections -ffunction-sections -Wl,--gc-sections -g -O2 -MT examples/C/glib/examples_C_glib_add_connection_libnm-add-connection-libnm.o -MD -MP -MF examples/C/glib/.deps/examples_C_glib_add_connection_libnm-add-connection-libnm.Tpo -c -o examples/C/glib/examples_C_glib_add_connection_libnm-add-connection-libnm.o `test -f 'examples/C/glib/add-connection-libnm.c' || echo '../'`examples/C/glib/add-connection-libnm.c ... ../src/libnm-client-public/nm-client.h:149:31: error: redefinition of typedef 'NMClient' is a C11 feature [-Werror,-Wtypedef-redefinition] typedef struct _NMClient NMClient; ^ Our code base is C11 internally (actually "-std=gnu11"), but this problem happens when we build the example. The warning is actually correct, because our public headers should be more liberal (and possibly be C99 or even C89, this is undefined). Fixes: 649314ddaa4c ('libnm: replace nm-types.h by defining the types in respective headers')
2022-05-12libnm: reorder includes in <NetworkManager.h> headerThomas Haller1-48/+57
We no longer have "nm-types.h", which forward declares most relevant typedefs. We also don't ensure that each header includes all the headers that it has a dependency (instead, we rely on the user to include "NetworkManager.h", which does the right thing). The "right thing" depends on doing doing it in the right order. Reorder the includes.
2022-05-12nmcli/devices: fix sorting of APsLubomir Rintel1-1/+1
Sort WEP access points as intended -- down, not up. Fixes: 550e3bbdd8f5 ('cli: device: color WEP APs differently in "wifi list"') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
2022-05-12nmcli/devices: check connection created with "wifi connect"Lubomir Rintel1-0/+6
We want to warn the user if they're connecting to an insecure network: $ nmcli d wifi IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY BA:00:6A:3C:C2:09 Secured Network Infra 2 54 Mbit/s 100 ▂▄▆█ WPA3 FA:7C:46:CC:9F:BE Ye Olde Wlan Infra 1 54 Mbit/s 100 ▂▄▆█ WEP $ nmcli d wifi connect 'Ye Olde Wlan' Warning: WEP encryption is known to be insecure. ... https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
2022-05-12nmcli/connections: export nmc_connection_check_deprecated()Lubomir Rintel2-5/+8
It's going to be useful with "nmcli dev wifi connect" that also creates a connection that should be checked. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
2022-05-11build/meson: workaround meson bug related to ternary expressionThomas Haller1-2/+1
On Debian 10, `apt-get install meson` gives meson-0.49.2-1. That version doesn't like certain ternary expressions (while some that we have are OK), which leads to a crash of meson. Avoid that. Fixes: bddffb1731c7 ('build/meson: honor prefix for udev_dir and don't use pkg-config')
2022-05-11gitlab-ci: avoid pager for "run-test.sh"Thomas Haller1-0/+2
In particular, `dpkg -l` likes to show a pager, when you are on the terminal. Being on the terminal happens, if you try to reproduce a test on your own container. So let's avoid that.
2022-05-11dhcp: merge branch 'th/dhcpv6-otherconf-ignore-addr'Thomas Haller3-49/+62
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1220
2022-05-11dhcp: fix ignoring addresses with DHCPv6 otherconf (O flag)Thomas Haller2-36/+45
With O flag (otherconf mode), don't add the IPv6 addresses to the collected lease. An alternative would be to add it initially, but ignore it when merging the configuration in NML3Cfg. The idea of that would be that if the mode switches from otherconf to managed, that we already have the address. However, depending on the mode we made a different DHCPv6 request. That means, if the mode changes we anyway cannot just use the previous lease, because it might not contain all the information. So it seems better to ignore the address early. Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration') https://bugzilla.redhat.com/show_bug.cgi?id=2083968 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/953 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1220
2022-05-11dhcp: fix setting "-S" flag for dhclient info-only requestsThomas Haller1-8/+13
Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
2022-05-11dhcp: always explicitly set request/information-request flags for internal ↵Thomas Haller1-5/+4
DHCPv6 client It seems clearer to explicitly set this always, and not rely on the defaults.
2022-05-11platform,core: merge branch 'th/platform-struct-packing'Thomas Haller4-59/+72
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1217
2022-05-11audit: handle error from audit_encode_nv_string()Thomas Haller1-2/+5
audit_encode_nv_string() is documented that it might fail. Handle the error. Also, the returned string was allocated with malloc(). We must free that with free()/nm_auto_free, not g_free()/gs_free.
2022-05-11platform: reorder fields in __NMPlatformIPRoute_COMMON for tight packingThomas Haller1-45/+44
2022-05-11platform: use flexible array members for ↵Thomas Haller3-13/+24
"NMPlatformIPAddress.address_ptr"/"NMPlatformIPRoute.network_ptr" Try to workaround a coverity warning: 30. NetworkManager-1.39.3/src/core/vpn/nm-vpn-connection.c:2000: overrun-buffer-val: Overrunning array "address.ax.address_ptr" of 1 bytes by passing it to a function which accesses it at byte offset 3.
2022-05-11build: merge branch 'th/meson-prefix-dir'Thomas Haller2-10/+18
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1221
2022-05-11meson/build: fix using correct prefix for "systemdsystemunitdir"Thomas Haller1-1/+1
We do the same with autotools. Well, almost the same. Of course, meson's define_variable only accepts a list of two strings, to define one variable. So we cannot also redefine "prefix", unlike configure.ac.
2022-05-11build/autotools: cleanup udev-dir option in configure.acThomas Haller1-5/+7
- also accept empty value to autodetect. This makes it similar to what is done with meson. - log the chosen udev-dir. - use ${prefix} instead of $(prefix). It's usually used at other places.
2022-05-11build/meson: honor prefix for udev_dir and don't use pkg-configThomas Haller1-4/+10
When building with `mesond -Dprefix=/tmp/nm`, then we would expect that udev files are installed there (wouldn't we?). The user can already explicitly set "-Dudev_dir=", or even disable installing the files with "-Dudev_dir=no". Note that meson be default pre-populates `get_option("prefix")`, so there is always something set. So we cannot just act on whether the user set a prefix. It seems to default to /usr/local. Note that package builds from Fedora spec file pass "-Dprefix=/usr". I think we should honor the prefix. However, then it seems wrong to also honor pkg-config at the same time. In particular, because `pkg-config --variable=udevdir udev` gives /usr/lib/udev. That means, if we would just prepend the default prefix "/usr" or "/usr/local" to "/usr/lib/udev" we get the wrong result. Note that we already to the same for autotools.
2022-05-10bridge: assume wired settings are therelr/bridge-wiredLubomir Rintel1-4/+5
We can now assert instead of checking. Also, let's move the whole get-the-mtu part down closer to where it is actually used. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1208
2022-05-10core/connection: ensure wired settings are around for bridgesLubomir Rintel3-1/+16
Bridges are wired ethernet bridges, it makes sense for them to have wired ethernet settings. Ensuring they always exist makes reapplying the MTU changes more convenient. The MTU for bridges is taken from wired settings, making it impossible to change and reapply it for connections that lack them (as reapply doesn't really cope well with addition and removal of settings). https://bugzilla.redhat.com/show_bug.cgi?id=2076131 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1208
2022-05-10bond: drop _get_option_or_default() and use _get_option_normalized()Fernando Fernandez Mancera3-15/+4
Currently nm_setting_bond_get_option_normalized() and nm_setting_bond_get_option_or_default() are identical functions. As the first one is exposed as public API and has a better name, let's drop the second one.
2022-05-09nmtui: merge branch 'gfm:nmtui-tun-tap'Thomas Haller2-7/+10
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1214
2022-05-09nmtui: add support for activating tun/tap connectionsOlivier Gayot2-0/+3
tun/tap connections can be created using a command such as: $ nmcli connection add type tun ifname tun0 mode tap owner 1000 They appear in nmcli connection as TYPE "tun". This patch adds the ability to activate and deactivate this type of connection using nmtui. Each connection of TYPE "tun" appears as: TUN/TAP (<ifname>) * <connection-name> Example: TUN/TAP (tap0) * bridge-slave-tap0 TUN/TAP (tap1) bridge-slave-tap1
2022-05-09nm-connection.c: replace !strcmp() expressions by nm_streq()Olivier Gayot1-7/+7
2022-05-09core: merge branch 'th/fix-clear-ip6-temp-addrs'Thomas Haller4-59/+115
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1209
2022-05-09l3cfg: refresh platform cache before creating prune list during L3Cfg commitThomas Haller1-0/+2
It seems, we should make decisions based on the latest state. Make sure to process all pending netlink events.
2022-05-09l3cfg: fix clearing IPv6 temporary addresses to avoid stale addressesThomas Haller3-59/+107
IPv6 temporary addresses are configured by kernel, with the "ipv6.ip6-privacy" setting ("use_tempaddr" sysctl) and the IFA_F_MANAGETEMPADDR flag. As such, the idea was that during reapply we would not remove them. However, that is wrong. The only case when we want to keep those addresses, is if during reapply we are going to configure the same primary address (with mngtmpaddr flag) again. Otherwise, theses addresses must always go away. This is quite serious. This not only affects Reapply. Also during disconnect we clear IP configuration via l3cfg. Have an ethernet profile active with "ipv6.ip6-privacy". Unplug the cable, the device disconnects but the temporary IPv6 address is not cleared. As such, nm_device_generate_connection() will now generate an external profile (with "ipv6.method=disabled" and no manual IP addresses). The result is, that the device cannot properly autoconnect again, once you replug the cable. This is serious for disconnect. But I could not actually reproduce the problem using reapply. That is, because during reapply we usually toggle ipv6_disable sysctl, which drops all IPv6 addresses. I still went through the effort of trying to preserve addresses that we still want to have, because I am not sure whether there are cases where we don't toggle ipv6_disable. Also, doing ipv6_disable during reapply is bad anyway, and we might want to avoid that in the future. Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
2022-05-09glib-aux: add nm_g_array_data() helperThomas Haller1-0/+6
It's annoying to do (arr ? arr->data : NULL) Especially, because usually you'd need to cast the above (which would have type (char *)).
2022-05-09all: merge branch 'th/clean-includes'Thomas Haller5-76/+74
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1205
2022-05-09daemon-helper: include "libnm-std-aux/nm-default-std.h" as first in ↵Thomas Haller1-2/+2
"nm-daemon-helper.c" All our sources should include one of the "nm-default*.h" headers first. That one drags in <config.h>, which must be included first and a few other basics. Which is the right "nm-default*.h" header depends on the component. In case of "nm-daemon-helper.c", it's "libnm-std-aux/nm-default-std.h".
2022-05-09std-aux: include default std-aux headers by "nm-default-std.h"Thomas Haller2-2/+5
2022-05-09all: drop redundant includesThomas Haller2-5/+0
2022-05-09code-style: fix wrong indentation for code commentsThomas Haller2-67/+67
2022-05-09glib-aux: merge branch 'th/str-buf-stack-allocated'Thomas Haller13-53/+136
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1203
2022-05-09glib-aux: avoid #if in "nm-str-buf.h"Thomas Haller1-4/+4
NM_MORE_ASSERT is a compile time constant. The compiler can optimize it away just fine.
2022-05-09glib-aux: drop nm_str_buf_init() for NM_STR_BUF_INIT()Thomas Haller13-30/+21
NM_STR_BUF_INIT() and nm_str_buf_init() were pretty much redundant. Drop one of them. Usually our pattern is that we don't have functions that return structs. But NM_STR_BUF_INIT() returns a struct, because it's convenient to use with nm_auto_str_buf NMStrBuf strbuf = NM_STR_BUF_INIT(...); So use that variant instead.
2022-05-09glib-aux: add support for starting with stack-allocated buffer in NMStrBufThomas Haller3-23/+115
Allow to initialize NMStrBuf with an externally allocated array. Usually a stack buffer. If the NMStrBuf grows beyond the size of that initial buffer, then it would switch using malloc. The idea is to support the common case where the result is small enough to fit on the stack. I always wanted to do such optimization because the main purpose of NMStrBuf is to put it on the stack and ad-hoc construct a string. I just figured, it would complicate the implementation and add a runtime overhead. But turns out, it doesn't really. The biggest question is how NMStrBuf should behave with a pre-allocated buffer? Turns out, most choices can be made in a rather obvious way. The only non-obvious thing is that nm_str_buf_finalize() would malloc() a buffer, but that too seems consistent and what a user would probably expect. As such, this doesn't seem to add unexpected semantics to the API.
2022-05-09device: commit l3cfg on link change only when the device is activatingBeniamino Galvani1-1/+2
On link change, the configuration should be reapplied only when the device is activating. Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration') https://bugzilla.redhat.com/show_bug.cgi?id=2079054 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1216
2022-05-06merge: branch 'lr/gtkdoc'Lubomir Rintel59-142/+95
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1211
2022-05-06libnm-client: fix some commentslr/gtkdocLubomir Rintel1-4/+4
Correct the mismatched arguments and descriptions, likely a copy & paste error.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-19 11:25:52 +0000