summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* release: bump version to 1.36.7 (development)1.36.7-devBeniamino Galvani2022-05-192-2/+2
|
* release: bump version to 1.36.61.36.6Beniamino Galvani2022-05-192-2/+2
|
* NEWS: updateBeniamino Galvani2022-05-191-2/+12
|
* c-rbtree: fix alignment assertion on m64kDavid Rheinsberg2022-05-181-4/+17
| | | | | | | | | | | | | | | | | We want to assert that our alignment-guarantees do not exceed the guarantees of the system-linker or system-allocator on the target platform. Hence, we check against max_align_t. This is a lower bound, but not the exact check we actually want. And as it turns out, on m64k it is too low. Add a static check against 4-byte alignment for m64k as a workaround. Reported-by: Michael Biebl Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com> https://github.com/c-util/c-rbtree/issues/9 https://github.com/c-util/c-rbtree/commit/eb778d39694a0f3389f2438bbc45fb21685a047d (cherry picked from commit 78831d127fa169b26783ccaa6b534edfbb0adad4) (cherry picked from commit a83c884fb6e13aad783d547691620d43bed4db84)
* device: don't require a hardware address for DHCPv6Beniamino Galvani2022-05-171-7/+0
| | | | | | | | | | | | | DHCPv4 requires a hardware address, while DHCPv6 does not. Anyway, the DHCP manager already checks that an address is available when needed, so drop the check here. Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1228 (cherry picked from commit 9bc7278da369d9dd69cc7687a5d050dfea793faa) (cherry picked from commit 1dbcc1c4412de43c6c5def417eef221b84535d7a)
* ndisc/tests: relex check in test_dns_solicit_loop()Thomas Haller2022-05-171-1/+5
| | | | | | | | | Dunno why this happens. Just silence it. nm:ERROR:../src/core/ndisc/tests/test-ndisc-fake.c:649:test_dns_solicit_loop: assertion failed (data.counter == 3): (2 == 3) (cherry picked from commit cb98616e026d9547279d7b2576f9e0245f5f7360) (cherry picked from commit 9858c34afb3bdc4c293b4b1cc8bd5ed49253dde9)
* libnm: merge branch 'th/libnm-8021x-empty-strings'Thomas Haller2022-05-173-35/+183
|\ | | | | | | | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/973 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1180 (cherry picked from commit 8df79f60d616e183257ae1a2c2b48beaf29e5eec)
| * libnm: normalize empty strings in 802-1x settingThomas Haller2022-05-172-0/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Supplicant does not allow setting certain properties to empty values. It also does not make sense. Also, ifcfg-rh writer uses svSetValueStr() for these properties, so the ifcfg plugin would always loose having hte values set to "". Also, you couldn't enter these strings in nmcli. It's fair to assume that it makes no sense to have these values set to an empty value. Since we cannot just tighten up verification to reject them, normalize them. It also seems that some GUI now starts setting domain_suffix_match to an empty string. Or maybe it was always doing it, and ifcfg plugin just hid the problem? Anyway, we have users out there who set these properties to "". https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/973 (cherry picked from commit 915e92392816a2fdcc574b63a4e8de1c7ae84b1b)
| * libnm: fix printing NULL value in NMSetting8021x.verify()Thomas Haller2022-05-171-25/+60
| | | | | | | | (cherry picked from commit 445e78377196d5b5321397594afed0b541fce052)
| * ifcfg-rh: move code around in write_8021x_setting()Thomas Haller2022-05-171-8/+8
| | | | | | | | | | | | | | Makes more sense, to not interrupt the construction of the phase2_auth string. (cherry picked from commit 91cbbd99b999c2972be0798c996fa9b86b09eae6)
| * ifcfg-rh/trivial: add fixme comments about lossy write/read of propertiesThomas Haller2022-05-171-2/+10
|/ | | | (cherry picked from commit 5f5641d304f1ac00066e8a716c99ae7f3688d330)
* core: merge branch 'th/fix-clear-ip6-temp-addrs'Thomas Haller2022-05-134-59/+115
|\ | | | | | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1209 (cherry picked from commit 452158a036701ef286f2bbe8d43d0561e84ea1a3) (cherry picked from commit 22affb0a166e38b4ada522ca5e00e3dce24018f7)
| * l3cfg: refresh platform cache before creating prune list during L3Cfg commitThomas Haller2022-05-131-0/+2
| | | | | | | | | | | | | | | | It seems, we should make decisions based on the latest state. Make sure to process all pending netlink events. (cherry picked from commit 9a69bc8d84fc9f9d4c28123dbbb37570008697df) (cherry picked from commit 1b9dfd30018fbb29e2ca3aacd31c21e1277113e0)
| * l3cfg: fix clearing IPv6 temporary addresses to avoid stale addressesThomas Haller2022-05-133-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') (cherry picked from commit 518f6124c6476e5f91b30b7d5583f494e84fd936) (cherry picked from commit 3bd210a8f1f8ee7469aba688d9f6b4d7ccac790b)
| * glib-aux: add nm_g_array_data() helperThomas Haller2022-05-131-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 *)). (cherry picked from commit 5ff08fbbea0acbc17bcb9c69901902456547515c) (cherry picked from commit 281b3e647377ffc37006474835c1d782c920c869)
* libnm: fix crash validating infiniband profiles for interface-nameThomas Haller2022-05-131-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') (cherry picked from commit fd5945b4084d72e3b77346a3ee363a9d3633cab7) (cherry picked from commit d476851ee79d8f37f19471353dc6a51a5a394335)
* dhcp: merge branch 'th/dhcpv6-otherconf-ignore-addr'Thomas Haller2022-05-133-47/+60
|\ | | | | | | | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1220 (cherry picked from commit 19a96f64edc8a1f592838f210d681e72b7af68a8) (cherry picked from commit fb5f2f25bc25a8e624013f819439671b766a14f0)
| * dhcp: fix ignoring addresses with DHCPv6 otherconf (O flag)Thomas Haller2022-05-132-34/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 (cherry picked from commit 2875ad7e504ab816614f328be4b3fb687e2da453) (cherry picked from commit 476e007d04cf5442699055e0ca98b71e69acf42e)
| * dhcp: fix setting "-S" flag for dhclient info-only requestsThomas Haller2022-05-131-8/+13
| | | | | | | | | | | | Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration') (cherry picked from commit 41df480fdd97d139287fce36947afd1a52ffda5b) (cherry picked from commit 29e90e472269a4f1e7cb7e4626708485f4e795ae)
| * dhcp: always explicitly set request/information-request flags for internal ↵Thomas Haller2022-05-131-5/+4
|/ | | | | | | | | | DHCPv6 client It seems clearer to explicitly set this always, and not rely on the defaults. (cherry picked from commit bacd3e14828b51d0016d06dffe3c8816b028a90c) (cherry picked from commit 6ad3694fc5f46f7be990a43e2f1eabc1edd128cc)
* audit: handle error from audit_encode_nv_string()Thomas Haller2022-05-131-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. Fixes: be49a59fb649 ('core: add audit support') (cherry picked from commit 6ebc6223033b50c660a88cb02e21697f8994b4c7) (cherry picked from commit 7f0d9a9091b21a7c336dbd85f85e473ccb389ae3)
* build/meson: avoid compiler warning generating "NM-1.0.gir"Thomas Haller2022-05-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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"') (cherry picked from commit e5d4194673073e6897a2514f326f245b8688bcc2) (cherry picked from commit 508c677f0cb084fc659ae5de4d1da66453c137a5)
* build/autotools: avoid compiler warning generating "NM-1.0.gir"Thomas Haller2022-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We passed on the CFLAGS, but they also contain "-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40" which causes compiler warnings: GISCAN src/libnm-client-impl/NM-1.0.gir /data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c: In function ‘dump_object_type’: /data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c:251:13: warning: Not available before 2.70 251 | if (G_TYPE_IS_FINAL (type)) | ^~~~~~~~~~~~~~~~~ /data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c: In function ‘dump_fundamental_type’: /data/src/NetworkManager/tmp-introspect_17ddrdb/NM-1.0.c:369:13: warning: Not available before 2.70 369 | if (G_TYPE_IS_FINAL (type)) | ^~~~~~~~~~~~~~~~~ Filter them out. See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331 (cherry picked from commit 1234e5583a09a618b930241a12b8a1d580493568) (cherry picked from commit 2ed877049b3604a15d04260d645b3cac79c54513)
* n-dhcp4/probe: forget lease after a NAKBeniamino Galvani2022-05-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a lease and we get a NAK renewing/rebinding it, the lease is lost. Without this, probe->current_lease remains set and after the next DISCOVER/OFFER round, any call to n_dhcp4_client_lease_select() will fail at: if (lease->probe->current_lease) return -ENOTRECOVERABLE; As in: [5325.1313] dhcp4 (veth0): send REQUEST of 172.25.1.200 to 255.255.255.255 [5325.1434] dhcp4 (veth0): received NACK from 172.25.1.1 [5325.1435] dhcp4 (veth0): client event 3 (RETRACTED) [5325.1436] dhcp4 (veth0): send DISCOVER to 255.255.255.255 [5325.1641] dhcp4 (veth0): received OFFER of 172.25.1.200 from 172.25.1.1 [5325.1641] dhcp4 (veth0): client event (OFFER) [5325.1641] dhcp4 (veth0): selecting lease failed: -131 (ENOTRECOVERABLE) Upstream: https://github.com/nettools/n-dhcp4/pull/33 Upstream: https://github.com/nettools/n-dhcp4/commit/e4af93228e3772bbb443ec1237252e6a2f3e3dd7 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/993 Fixes: e43b1791a382 ('Merge commit 'e23b3c9c3ac86b065eef002fa5c4321cc4a87df2' as 'shared/n-dhcp4'') (cherry picked from commit e141cd45d610164ec9a041856677b2ad426c2c20) (cherry picked from commit e056a68d218ad51d801cfaff95afa3f8cbcfa619)
* ovsdb: fix memory leakBeniamino Galvani2022-05-131-20/+18
| | | | | | | | | | @error was leaked when created inside the function. While at it, remove the goto. Fixes: 830a5a14cb29 ('device: add support for OpenVSwitch devices') (cherry picked from commit 6f6c044739a04e1a3b59274853ca869bcbfd30d8) (cherry picked from commit e8d6ad9d127e5ebae2047c663e4b2925d5c2f205)
* build/meson: add dependency libnm_client_public_dep for "libnm-client-test"Yi Zhao2022-05-131-0/+1
| | | | | | | | | | | | | | | | Fix parallel build error: | In file included from ../NetworkManager-1.36.0/src/libnm-client-test/nm-test-utils-impl.c:10: | ../NetworkManager-1.36.0/src/libnm-client-public/NetworkManager.h:47:10: fatal error: nm-enum-types.h: No such file or directory | 47 | #include "nm-enum-types.h" | | ^~~~~~~~~~~~~~~~~ Signed-off-by: Yi Zhao <yi.zhao@windriver.com> Fixes: a03a03fbe9a8 ('libnm/tests: add static helper library "src/libnm-client-test/"') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1206 (cherry picked from commit 53952446a7c4cc898932478419389f01ecf6f115) (cherry picked from commit 5c3d538d6da4a220da263d4aa986b052bf59bd1b)
* l3cfg: drop NM_L3_CFG_COMMIT_TYPE_ASSUME and assume_config_onceFernando Fernandez Mancera2022-05-1211-137/+34
| | | | | | | | | | | | | | | | | | | | | | 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 (cherry picked from commit bf5927b978fccec1390bcc7d3d5719d7fe7c3450) (cherry picked from commit a494c00901a56afe422c4944875de0340d305e8a)
* platform: add semantic comparison for IP addresses and add ↵Thomas Haller2022-05-123-72/+224
| | | | | | | | | | | | | | | | | | | | | | | | "nm_platform_vtable_address" We already have a comparison of NMPlatformIPXAddress with the modes "full" and "id". The former is needed to fully compare two addresses, the latter as identity for tracking addresses in the cache. In NetworkManager we also use the NMPlatformIP[46]Address structure to track the addresses we want to configure. When we add them in kernel, we will later see them in the platform cache. However, some fields will be slightly different. For example, "addr_source" address will always be "kernel", because that one is not a field we configure in kernel. Also, the "n_ifa_flags" probably differ (getting "permanent" and "secondary" flags). Add a compare function that can ignore such differences. Also add nm_platform_vtable_address for accessing the IPv4 and IPv6 methods generically (based on an "IS_IPv4" variable). (cherry picked from commit ef1b60c061f85b60329d37d62dc81683ff56f4b7) (cherry picked from commit ea6625ce97629b287f484e0d5caeb0d08ed44843)
* platform: make NMPlatformVTableAddress struct smaller and pack NMPObjectTypeThomas Haller2022-05-122-4/+4
| | | | | (cherry picked from commit 7c92663f8d79375c78f6917d4c6e005d7accf2a6) (cherry picked from commit 3a98ecfa0edce51c5ed8446bc3a74efc6ec6ac65)
* platform: make "now" timestamp an in/out parameter to nmp_utils_lifetime_get()Thomas Haller2022-05-124-13/+17
| | | | | | | | | | | | | | | | | | | | | nmp_utils_lifetime_get() calculates the lifetime of addresses, and it bases the result on a "now" timestamp. If you have two addresses and calculate their expiry, then we want to base it on top of the same "now" timestamp, meaning, we should only call nm_utils_get_monotonic_timestamp_sec() once. This is also a performance optimization. But much more importantly, when we make a comparison at a certain moment, we need that all sides have the same understanding of the current timestamp. But nmp_utils_lifetime_get() does not always require the now timestamp. And the caller doesn't know, whether it will need it (short of knowing how nmp_utils_lifetime_get() is implemented). So, make the now parameter an in/out argument. If we pass in an already valid now timestamp, use that. Otherwise, fetch the current time and also return it. (cherry picked from commit deb37401e95d4ea0025e406424c8da7c10bc9712) (cherry picked from commit 9e40474c715e995c000b29db030b4a4990cc6e51)
* glib-aux: add nm_utils_get_monotonic_timestamp_sec_cached() helperThomas Haller2022-05-121-0/+6
| | | | | (cherry picked from commit 3f4586532ffb8db2136bbb4ef906fd21d17d5bd2) (cherry picked from commit 66237888e78aeae2f348b6b97c39c203a34ab7be)
* device: commit l3cfg on link change only when the device is activatingBeniamino Galvani2022-05-091-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 (cherry picked from commit 77c8b2960abfc3a7b05ee1bc7dbfe382e9b64a3e) (cherry picked from commit b596ad1058fdc3cc40314f24e64db08f12fc0d1e)
* NEWS: updatebg/nm-1-36Beniamino Galvani2022-04-291-0/+16
|
* device: set MTU after attaching bond portThomas Haller2022-04-291-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 (cherry picked from commit 6804c2ba0479a44c314a61bbdcc29e0cd6987166) (cherry picked from commit 352e8bb86547f849ddd05cffce52a2e7760ce853)
* settings: fix assertion failure in NMSettings' _startup_complete_check()Thomas Haller2022-04-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This probably has no bad effects when building without more-asserts. #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f7ead0564a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f7ead009d06 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f7eacfdc7d3 in __GI_abort () at abort.c:79 #4 0x00007f7ead1fed4c in g_assertion_message (domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>, message=<optimized out>) at ../glib/gtestutils.c:3065 #5 0x00007f7ead25f98f in g_assertion_message_expr (domain=0x560964f8b7e9 "nm", file=0x560964f83da8 "src/core/settings/nm-settings.c", line=640, func=0x56096504a390 <__func__.44.lto_priv.1> "_startup_complete_check", expr=<optimized out>) at ../glib/gtestutils.c:3091 #6 0x0000560964ed710e in _startup_complete_check (self=0x560966d1d030, now_msec=<optimized out>) at src/core/settings/nm-settings.c:640 #7 0x0000560964ed7d9b in _startup_complete_notify_connection (self=0x560966d1d030, sett_conn=<optimized out>, forget=<optimized out>) at src/core/settings/nm-settings.c:704 #8 0x0000560964edd070 in _connection_changed_delete (self=0x560966d1d030, storage=<optimized out>, sett_conn=0x560966cedbc0, allow_add_to_no_auto_default=<optimized out>) at src/core/settings/nm-settings.c:1244 #9 0x0000560964edd948 in _connection_changed_process_one (update_reason=(NM_SETTINGS_CONNECTION_UPDATE_REASON_IGNORE_PERSIST_FAILURE | NM_SETTINGS_CONNECTION_UPDATE_REASON_CLEAR_SYSTEM_SECRETS | NM_SETTINGS_CONNECTION_UPDATE_REASON_UPDATE_NON_SECRET | unknown: 0x5400), override_sett_flags=0, sett_mask=NM_SETTINGS_CONNECTION_INT_FLAGS_NONE, sett_flags=1725440360, allow_add_to_no_auto_default=0, sett_conn_entry=0x560966d1d030, self=<optimized out>) at src/core/settings/nm-settings.c:1294 #10 _connection_changed_process_all_dirty (self=<optimized out>, allow_add_to_no_auto_default=<optimized out>, sett_flags=<optimized out>, sett_mask=<optimized out>, override_sett_flags=<optimized out>, update_reason=<optimized out>) at src/core/settings/nm-settings.c:1335 #11 0x0000560964eeb8ec in nm_settings_delete_connection (allow_add_to_no_auto_default=648659760, sett_conn=<optimized out>, self=0x560966d1d030) at src/core/settings/nm-settings.c:2457 #12 nm_settings_connection_delete (self=<optimized out>, allow_add_to_no_auto_default=648659760) at src/core/settings/nm-settings-connection.c:637 #13 0x0000560964eebebd in delete_auth_cb (self=0x560966cedbc0, context=0x7f7e9c0170a0, subject=0x560966cc5ed0, error=0x0, data=<optimized out>) at src/core/settings/nm-settings-connection.c:1877 #14 0x0000560964ec9778 in pk_auth_cb (auth_manager=<optimized out>, auth_call_id=<optimized out>, is_authorized=1, is_challenge=<optimized out>, auth_error=<optimized out>, user_data=0x560966e16980) at src/core/settings/nm-settings-connection.c:1262 #15 0x0000560964db9a28 in _call_id_invoke_callback (error=0x0, is_challenge=0, is_authorized=1, call_id=0x560966ddeb00) at src/core/nm-auth-manager.c:180 #16 _call_on_idle (user_data=user_data@entry=0x560966ddeb00) at src/core/nm-auth-manager.c:284 #17 0x00007f7ead23111b in g_idle_dispatch (source=0x560966e50190, callback=0x560964db9900 <_call_on_idle>, user_data=0x560966ddeb00) at ../glib/gmain.c:5848 #18 0x00007f7ead234d4f in g_main_dispatch (context=0x560966cd1e20) at ../glib/gmain.c:3337 #19 g_main_context_dispatch (context=0x560966cd1e20) at ../glib/gmain.c:4055 #20 0x00007f7ead289608 in g_main_context_iterate.constprop.0 (context=0x560966cd1e20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4131 #21 0x00007f7ead234463 in g_main_loop_run (loop=0x560966caf010) at ../glib/gmain.c:4329 #22 0x0000560964cb7515 in main (argc=<optimized out>, argv=<optimized out>) at src/core/main.c:509 Fixes: 3df662f534c4 ('settings: rework wait-device-timeout handling and consider device compatibility') (cherry picked from commit 9046975a81cae3be0896bacceb84dc671e07f23c) (cherry picked from commit 29fe4035c1c83b921ddeb9f74a2e97b4569ed66d)
* libnm: fix update of cached option names in nm_setting_option_set()Thomas Haller2022-04-291-3/+3
| | | | | | | | | This is severe. We cache the list of names, and we must invalidate the cache when the names change. Otherwise, out-of-bound access and crash. Fixes: d0192b698e68 ('libnm: add nm_setting_option_set(), nm_setting_option_get_boolean(), nm_setting_option_set_boolean()') Fixes: 150af44e1042 ('libnm: add nm_setting_option_get_uint32(), nm_setting_option_set_uint32()') (cherry picked from commit 22dcfb3a6770e9893440f6a99bed3aaf16e083b8)
* bridge: fix reentrant call for bluetooth NAP bridgeFrancisco Blas Izquierdo Riera (klondike)2022-04-291-10/+21
| | | | | | | | | | | | | | | | | Currently NetworkManager fails to establish a NAP bridge because it never gets out of the stage2. This is caused because when making the BlueZ callback reentrant we return NM_ACT_STAGE_RETURN_POSTPONE even after registration has succeeded. This patch changes registration to a three state automaton instead of a boolean. This allows distinguishing when we are waiting for registration to finish and when it is done and therefore ensures that when the stage2 is called again by the callback the result is success so NetworkManager can proceed to the IP configuration. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1181 (cherry picked from commit 8f7e295cbf98ca220fbd13336bb0cdd4d477bd27)
* libnm: merge branch 'BryanJacobs:main'Thomas Haller2022-04-292-72/+121
|\ | | | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1164 (cherry picked from commit 979dbd6d0dfd96c3397b3d437822647b5a3fc0f5)
| * libnm/tests: test that nm_vpn_service_plugin_read_vpn_details() does not ↵Thomas Haller2022-04-291-7/+88
| | | | | | | | | | | | consume "QUIT" command (cherry picked from commit b1b1ee8cc41af4f57902560f6769daf15852311e)
| * libnm: handle NUL characters in nm_vpn_service_plugin_read_vpn_details() and ↵Thomas Haller2022-04-292-2/+14
| | | | | | | | | | | | | | | | | | | | fix test We expect to read NUL terminated strings. Upon NUL, we should do something. Treat it as a line break. Fixes: 8ae9cf4698b4 ('Revert "libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()"') (cherry picked from commit 6235815248314c0bd3deb485692881620a859cf9)
| * Revert "libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()"Bryan Jacobs2022-04-291-64/+20
|/ | | | | | | | | | | | | | | | This partially reverts commit 4a9fcb0fc32e, which replaced one-byte reads with buffered ones in the VPN service plugin. Unfortunately the buffering means that commands coming after the magic "DONE" string were being pulled into the buffer. Secrets agents expect a "QUIT" to come after the "DONE", and since with buffering "QUIT" was in the buffer, this led to a twenty-second delay on every VPN connection using a secrets manager. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1164 Fixes: 4a9fcb0fc32e ('libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()') (cherry picked from commit 8ae9cf4698b4fadae8cfbfbc801cf93d2385629d)
* platform: merge branch 'th/platform-address-order' (part 1)Thomas Haller2022-04-292-119/+202
|\ | | | | | | | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1168 (cherry picked from commit 8b95693985f52df631b822fda754b81007c3ff5d) (cherry picked from commit 14052c847c53c79549172f126a8cfb7eaba1049f)
| * platform: track IPv4 subnets with prefix length in nm_platform_ip_address_sync()Thomas Haller2022-04-291-21/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The entire point of the dance in nm_platform_ip_address_sync() is to ensure that conflicting IPv4 addresses are in their right order, that is, they have the right primary/secondary flag. Kernel only sets secondary flags for addresses that are in the same subnet, and we also only care about the relative order of addresses that are in the same subnet. In particular, because we rely on kernel's "secondary" flag to implement this. But kernel only treads addresses as secondary, if they share the exact same subnet. For example, 192.168.0.5/24 and 192.168.0.6/25 would not be treated as primary/secondary but just as unrelated addresses, even if the address cleared of it's host part is the same. This means, we must not only hash the network part of the addresses, but also the prefix length. Implement that, by tracking the full NMPObject. (cherry picked from commit 619dc2fcab809a1cae831c1866ce93189b575d53) (cherry picked from commit 0bdb2e97d9a6bcd86889fb09765835a5886d13fb)
| * platform: move known_subnets variable to inner scope in ↵Thomas Haller2022-04-291-5/+3
| | | | | | | | | | | | | | nm_platform_ip_address_sync() (cherry picked from commit e1431b43a2e02bdd010474df40ccf4417e8b7d08) (cherry picked from commit a8e96e3c4b539391833b74432c3200df4e3a8223)
| * platform: fix undefined behavior for pointer comparison in ↵Thomas Haller2022-04-291-2/+2
| | | | | | | | | | | | | | | | ip4_addr_subnets_is_plain_address() Fixes: 2f68a5004153 ('platform: fix the order of addition of primary and secondary IPv4 addresses') (cherry picked from commit 40f22e69c8c03fbbe40f3ba701c3540470f49dfe) (cherry picked from commit 41b56cb2b9397407d24e00f95ba4ffb009212040)
| * platform: fix returning error from nm_platform_ip_address_sync()Thomas Haller2022-04-291-14/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | None of the callers really handle the return value of nm_platform_ip_address_sync() or whether the function encountered problems. What would they anyway do about that? For IPv4 we were already ignoring errors to add addresses, but for IPv6 we aborted. That seems wrong. As the caller does not really handle errors, I think we should follow through and add all addresses in case of error. Still, also collect a overall "success" of the function and return it. (cherry picked from commit cedaa191d44fede4048a581f2cd132ec6b03d6e9) (cherry picked from commit 8736cc86187d176ca7a7f1dbe5bdee0786c2e037)
| * platform: fix address order in nm_platform_ip_address_sync()Thomas Haller2022-04-291-81/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the past, nm_platform_ip_address_sync() only had the @known_addresses argument. We would figure out which addresses to delete and which to preserve, based on what addresses were known. That means, @known_addresses must have contained all the addresses we wanted to preserve, even the external ones. That approach was inherently racy. Instead, nowadays we have the addresses we want to configure (@known_addresses) and the addresses we want to delete (@prune_addresses). This started to change in commit dadfc3abd510 ('platform: allow injecting the list of addresses to prune'), but only commit 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration') actually changed to pass separate @prune_addresses argument. However, the order of IP addresses matters and there is no sensible kernel API to configure the order (short of adding them in the right order), we still need to look at all the addresses, check their order, and possibly delete some. That is, we need to handle addresses we want to delete (@prune_addresses) but still look at all addresses in platform (@plat_addresses) to check their order. Now, first handle @prune_addresses. That's simple. These are just the addresses we want to delete. Second, get the list of all addresses in platform (@plat_addresses) and check the order. Note that if there is an external address that interferes with our desired order, we will leave it untouched. Thus, such external addresses might prevent us from getting the order as desired. But that's just how it is. Don't add addresses outside of NetworkManager to avoid that. Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration') (cherry picked from commit 80f8e23992b58aa0b6fd88de0d3973eea51691a4) (cherry picked from commit 4c3197b37790c6c89c7b3df0e92a26e1f8719a5a)
| * platform: add nm_platform_ip_address_delete() helperThomas Haller2022-04-291-0/+23
|/ | | | | (cherry picked from commit a60a262574206976eacc405633c059e0f375f0a8) (cherry picked from commit 0fc40735ab582f2ff9f319043d77d5f40253f103)
* configure.ac: fix a syntax errorLubomir Rintel2022-04-211-1/+1
| | | | | | | | | | | | | 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') (cherry picked from commit a8284b1d3b967789066c76c39660a91565fb7833)
* supplicant: Disable WPA3 transition mode when PMF is set to disabled谢致邦 (XIE Zhibang)2022-04-111-1/+12
| | | | | | | | | | | | | | | | | According to WPA3_Specification_v3.0 section 2.3, when operating in WPA3-Personal transition mode an AP: - shall set MFPC to 1, MFPR to 0. Therefore, do not operate in WPA3-Personal transition mode when PMF is set to disabled. This also provides a way to be compatible with some devices that are not fully compatible with WPA3-Personal transition mode. Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1186 (cherry picked from commit b6eb237a271c91f6ca9d74f0db8f7e80b9998d51) (cherry picked from commit a0988868ba7b4390790cab43cca5103f80a6a300)
View Lorry Controller Status