summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* testmelr/testmeLubomir Rintel2022-09-051-0/+5
|
* xdevLubomir Rintel2022-09-051-2/+3
|
* manager: don't assume connection if device has ActRequestLubomir Rintel2022-09-051-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The @dracut_NM_vlan_over_team_no_boot sometimes fails, among other things, because it fails to assume an indicated connection after a restart. That seems to happen because after the decision to activate the indicated connection, the device does not move from DISCONNECTED state quickly enough. Another assumption recheck runs in between and decides to generate a connection, because the assume state was already reset in between. First start, creates and activates b3a61b68-f744-4a4c-a513-61399c154a67 on vlan0017: NetworkManager (version 1.41.1-30921.55767cf5c5.el9) is starting... (asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe) ... settings: update[b3a61b68-f744-4a4c-a513-61399c154a67]: adding connection "vlan0017" (45113870df0a4cfb/keyfile) Second start: NetworkManager (version 1.41.1-30921.55767cf5c5.el9) is starting... (after a restart, asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe) Assumption attempt successfully picks the right connection and thus proceeds to reset the assume state: manager: (vlan0017): assume: will attempt to assume matching connection 'vlan0017' (b3a61b68-f744-4a4c-a513-61399c154a67) (indicated) device[c7c5101cf0b73f5f] (vlan0017): assume-state: set guess-assume=0, connection=(null) Everything great so far, activation of the right connection is enqueued and the device moves away from unavailable state. However, the activation can't proceed immediately: device (vlan0017): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume') device (vlan0017): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'assume') active-connection[0x55ba1162f1c0]: set device "vlan0017" [0x55ba1163c4f0] device[c7c5101cf0b73f5f] (vlan0017): queue activation request waiting for carrier Now another assumption attempt is done. The original assume state is gone, so a connection is generated: platform-linux: UDEV event: action 'add' subsys 'net' device 'vlan0017' (6); seqnum=1959 device[c7c5101cf0b73f5f] (vlan0017): queued link change for ifindex 6 manager: (vlan0017): assume: generated connection 'vlan0017' (57627119-8c20-4f9e-bf4d-4fc427b4a6a9) keyfile: commit: 57627119-8c20-4f9e-bf4d-4fc427b4a6a9 (vlan0017) added as "/run/NetworkManager/system-connections/vlan0017-57627119-8c20-4f9e-bf4d-4fc427b4a6a9.nmconnection" (nm-generated,volatile,external) I think this shouldn't have happened. We've picked the correct connection already and it's enqueued for activation! Let's not assume anything if there's an activation request already. Fixes-test: @dracut_NM_vlan_over_team_no_boot
* team: back off a little when re-spawning teamdLubomir Rintel2022-09-051-2/+18
| | | | | | | | It might have dropped off for a reason (e.g. D-Bus itself has gone away, because the system is transitioning from initrd to real root). Give things a few seconds to cool off, just to be nice. That shouldn't be a big deal, the link should still be operational.
* device: don't ignore external slave removalsLubomir Rintel2022-09-051-6/+10
| | | | | | | | | | | | | | | | | | We've been outright ignoring master-slave checks if the link ended up without a master since commit 2e22880894cf ('device: don't remove the device from master if its link has no master'). I have no idea why that was done -- I suppose it was due to platform link change without a master arriving at a wrong time, making us thing the master was removed externally when in reality the link was not enslaved yet. For this reason I'm now consulting priv->is_enslaved. It's also possible that bulk of logic that has been added into device_recheck_slave_status() since deals with the problematic case already. Morale: Write better commit messages of future you is going to be upset Fixes: 2e22880894cf ('device: don't remove the device from master if its link has no master')
* device: don't emit recheck-assume if there is a queued activation requestBeniamino Galvani2022-09-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The @dracut_NM_vlan_over_team_no_boot sometimes fails, among other things, because it fails to assume an indicated connection after a restart. That seems to happen because after the decision to activate the indicated connection, the device does not move from DISCONNECTED state quickly enough. Another assumption recheck runs in between and decides to generate a connection, because the assume state was already reset in between. First start, creates and activates b3a61b68-f744-4a4c-a513-61399c154a67 on vlan0017: NetworkManager (version 1.41.1-30921.55767cf5.el9) is starting... (asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe) ... settings: update[b3a61b68-f744-4a4c-a513-61399c154a67]: adding connection "vlan0017" (45113870df0a4cfb/keyfile) Second start: NetworkManager (version 1.41.1-30921.55767cf5.el9) is starting... (after a restart, asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe) Assumption attempt successfully picks the right connection and thus proceeds to reset the assume state: manager: (vlan0017): assume: will attempt to assume matching connection 'vlan0017' (b3a61b68-f744-4a4c-a513-61399c154a67) (indicated) device[c7c5101cf0b73f5f] (vlan0017): assume-state: set guess-assume=0, connection=(null) Everything great so far, activation of the right connection is enqueued and the device moves away from unavailable state. However, the activation can't proceed immediately: device (vlan0017): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume') device (vlan0017): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'assume') active-connection[0x55ba1162f1c0]: set device "vlan0017" [0x55ba1163c4f0] device[c7c5101cf0b73f5f] (vlan0017): queue activation request waiting for carrier Now another assumption attempt is done. The original assume state is gone, so a connection is generated: platform-linux: UDEV event: action 'add' subsys 'net' device 'vlan0017' (6); seqnum=1959 device[c7c5101cf0b73f5f] (vlan0017): queued link change for ifindex 6 manager: (vlan0017): assume: generated connection 'vlan0017' (57627119-8c20-4f9e-bf4d-4fc427b4a6a9) keyfile: commit: 57627119-8c20-4f9e-bf4d-4fc427b4a6a9 (vlan0017) added as "/run/NetworkManager/system-connections/vlan0017-57627119-8c20-4f9e-bf4d-4fc427b4a6a9.nmconnection" (nm-generated,volatile,external) I think this shouldn't have happened. We've picked the correct connection already and it's enqueued for activation! Change the check in nm_device_emit_recheck_assume() to also consider any queued activation. Fixes-test: @dracut_NM_vlan_over_team_no_boot Co-authored-by: Lubomir Rintel <lkundrak@v3.sk> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1351
* libnm: merge branch 'th/libnm-doc-annotation-fixes'Thomas Haller2022-09-0211-53/+52
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1352
| * libnm: fix invalid doc annotations for missing end tagThomas Haller2022-09-021-0/+1
| |
| * libnm: style cleanups for property annotationsThomas Haller2022-09-029-24/+46
| | | | | | | | | | | | | | The parser will become stricter, and expect certain things. The strictness should help, to avoid writing wrong annotations. Adjust for that.
| * libnm: avoid "tag:" text inside documentationThomas Haller2022-09-021-2/+2
| | | | | | | | | | | | | | | | The parser is reworked, and this line could be wrongly parsed because it starts with " * value:" which could be misinterpreted as a tag. It actually won't be parsed wrongly and is not parsed wrongly now. Still, avoid this potential ambiguity by breaking the line differently.
| * libnm: drop invalid "---ifcfg-rh---" blocksThomas Haller2022-09-021-24/+0
| |
| * libnm: fix documentation annotations for ifcfg-rh pluginThomas Haller2022-09-023-3/+3
|/
* team: restore port configuration after teamd respawnLubomir Rintel2022-09-021-16/+40
| | | | | | | | | | | | | | | If teamd crashes, we restore it. That's very nice, but if it really crashed then it left ports attached and the slave connections are not going to fail and the port configuration (e.g. priority or link watcher) in teamd's memory will be gone. This will restore the port configuration when the teamd connection is re-established. This probably also fixes a race where a slave connection would be enslaved (only possible externally and manually?) while we didn't establish a connection to teamd yet. We'll just send the port configuration in once're connected. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1361
* team: trivial: use a variable instead of nm_device_get_ip_iface() callsLubomir Rintel2022-09-021-10/+9
| | | | | | This reads a little better and performs marginally better. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1361
* ovs: merge branch 'add-ovs-option'Vojtech Bubela2022-09-027-5/+65
|\ | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1322
| * ovs: add ofport_request option to ovs interfaceadd-ovs-optionVojtech Bubela2022-09-027-5/+65
|/ | | | | | Add option to set ofport_request when configuring ovs interface. When connection with ofport_request configured is activated ovsdb will first try to activated on the port set by ofport_request.
* version: reformat file for latest styleThomas Haller2022-09-011-35/+34
| | | | | | | | the .h.in file is not formatted by our nm-code-format.sh file. It also contains .in template parameters that the formatting would destroy. Still, follow our current style and reformat the parts manually.
* contrib: add "reset" command to "nm-in-container.sh"Thomas Haller2022-09-011-9/+14
| | | | | | It's between "stop" and "clean". It removes the container, but keeps the container images. This is to fast restart without rebuilding the container (image).
* nmcli: don't translate "%s"Lubomir Rintel2022-09-011-1/+1
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1354
* manager: drop useless use of a format stringLubomir Rintel2022-09-011-1/+1
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1355
* version: add 1.42 macrosVojtech Bubela2022-08-312-0/+15
|
* nmcli: merge branch 'th/nmcli-modify-uuid'Thomas Haller2022-08-3110-166/+266
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1349
| * NEWS: updateThomas Haller2022-08-311-0/+3
| |
| * nmcli: allow setting the "connection.uuid" for new profilesThomas Haller2022-08-311-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because, why not? The client side determines the UUID, so there is no security implication by letting the nmcli user explicitly choose it. $ nmcli connection add type ethernet con-name x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011 Connection 'x' (6965f79c-4424-4918-98e8-3c0982434011) successfully added. $ nmcli connection add type ethernet con-name x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011 Error: Failed to add 'x' connection: a connection with this UUID already exists $ nmcli connection modify x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011 $ nmcli connection modify x connection.uuid 6965f79c-4424-4918-98e8-3c0982434012 Error: failed to modify connection.uuid: the property can't be changed.
| * nmcli: allow changing the UUID of a profile in offline modeThomas Haller2022-08-314-3/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is useful to modify the UUID in offline mode. Otherwise, it's cumbersome to clone a profile, because the cloned profile will have the same UUID (and NetworkManager cannot load them both at the same time). umask 077 nmcli --offline connection modify \ connection.id profile2 \ connection.uuid new \ < /etc/NetworkManager/system-connections/profile1.nmconnection \ > /etc/NetworkManager/system-connections/profile2.nmconnection \ The doctext doesn't actually work for `man nm-settings-nmcli`. The generation of our docs is still an incomprehensible mess that needs fixing.
| * nmcli: support changing the connection type in offline modeThomas Haller2022-08-311-14/+30
| |
| * nmcli: add get_env_flags() accessor to NMMetaEnvironment for checking ↵Thomas Haller2022-08-312-0/+28
| | | | | | | | | | | | | | | | offline mode We will want to know whether we are in offline mode. Add an accessor to get environment flags, which libnmc-setting can use.
| * libnmc: avoid "g_set_error(error, 1, 0, ...)" and use nm_utils_error_set()Thomas Haller2022-08-311-145/+161
| | | | | | | | | | | | | | | | We really should not pass bogus values "1, 0" to g_set_error(). As we don't care about a particular error code, use NM_UTILS_ERROR_UNKNOWN. While at it, use nm_utils_error_set() everywhere.
| * glib-aux/trivial: fix typo in commentThomas Haller2022-08-311-1/+1
| |
| * glib-aux: first try stack allocated temporary buffer in ↵Thomas Haller2022-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | nm_uuid_generate_from_strings() Try to first use a stack allocated buffer for the temporary string. Only if the data is too large, NMStrBuf will automatically grow the buffer on the heap. In many cases, this buffer will be large enough, and we can avoid the heap allocation.
| * glib-aux: fix spurious semicolon after NM_STR_BUF_INIT() macrosThomas Haller2022-08-311-2/+2
|/ | | | | | It's wrong, and it breaks certain uses. Fixes: 13d25f9d0b2f ('glib-aux: add support for starting with stack-allocated buffer in NMStrBuf')
* checkpatch.pl: discourage g_str_hash()/g_direct_hash() and g_direct_equal()Thomas Haller2022-08-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | - instead of g_str_hash()/g_direct_hash(), use our own functions nm_str_hash()/nm_direct_hash(). Those use siphash24 with a random seed. - don't pass g_direct_equal() to GHashTable. When omitting the equal function, it falls back to direct pointer comparison, which is likely faster. In any case, it's consistent to not use g_direct_hash() when using pointer equality. - instead of g_int_hash()/g_int64_hash()/g_double_hash(), use our nm_pint_hash()/nm_pint64_hash()/nm_pdouble_hash(). The latter two don't exist yet. The reason is that we want to use siphash24. Yes, our name differs from glib's. Our naming seems to make sense to me however, because we also have nm_pstr_hash(), nm_pdirect_hash() and even nm_ppdirect_hash() for following the pointers. Naming is hard. - instead of g_int_equal()/g_int64_equal()/g_double_equal() use our nm_pint_equal()/nm_pint64_equal()/nm_pdouble_equal(). The latter two don't exist yet. The reason is purely naming consistency since our hash variants follow the other name.
* cloud-setup,glib-aux: use NULL instead of g_direct_equal() for hash tablesThomas Haller2022-08-312-8/+7
|
* initrd: avoid duplicate file check and NULL pointer dereference in ↵Thomas Haller2022-08-311-7/+9
| | | | | | | | | | | | | nmi_ibft_read() - move the second g_file_test() inside the if-block. No need to check twice, if the file exists. - load_one_nic() can return NULL. Use nm_g_hash_table_lookup() to avoid NULL pointer assertion. - use cleanup attribute for "nic" variable, and explicitly pass ownership on with g_steal_pointer().
* device: load only required modulesAdrian Freihofer2022-08-311-13/+22
| | | | | | | | | | Honor firewall-backend for modules loading and ip forwarding enabling as well: * iptables: do not load nftables modules * nftables: do not load iptables modules * none: do not load any modules and do not enable ip forwarding https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1356
* wifi: use GSource instead of source ID for Wi-Fi scan_kickoff_timeoutThomas Haller2022-08-301-21/+23
|
* wifi: allow explicit scans during AP/ADHOC modesThomas Haller2022-08-301-1/+4
| | | | | | | The user might still want to see the scan list, to decide whether to stop the hotspot/ADHOC connection and connect to something else. Allow explicit scans.
* NEWS: updateThomas Haller2022-08-261-0/+10
|
* release: bump version to 1.41.1 (development)1.41.1-devThomas Haller2022-08-26171-1824/+1922
|\
| * NEWS: updateAna Cabral2022-08-261-5/+3
| |
| * tests: fix "test-client.py" for early python3 versionsThomas Haller2022-08-261-3/+1
| | | | | | | | | | | | | | ModuleNotFoundError was only introduced in later python 3 versions. Use just "ImportError", which is the parent class anyway. Fixes: f7e484c8eda4 ('tests: fix "test-client.py" ignoring missing "NM" module')
| * style: fix code formattingThomas Haller2022-08-251-4/+1
| | | | | | | | Fixes: eec9efd98950 ('glib-aux: fix nicks for zero flag in nm_utils_enum_to_str()')
| * dhcp: merge branch 'bg/restart-dhcp-on-mac-change'Thomas Haller2022-08-255-12/+17
| |\ | | | | | | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=2110000 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1343
| | * device: restart DHCP when the MAC changesBeniamino Galvani2022-08-251-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the MAC changes there is the possibility that the DHCP client will not be able to renew the address because it uses the old MAC as CHADDR. Depending on the implementation, the DHCP server might use CHADDR (so, the old address) as the destination MAC for DHCP replies, and those packets will be lost. To avoid this problem, restart the DHCP client when the MAC changes. https://bugzilla.redhat.com/show_bug.cgi?id=2110000
| | * core: log when dynamic IP configuration is restarted and whyBeniamino Galvani2022-08-255-9/+11
| |/
| * device: wait for carrier on unavailable device even when it gets a ↵Lubomir Rintel2022-08-251-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | connection assumed The test in question leaves the device with a master set, which caused a connection to get assumed and therefore the previous fix didn't kick in. Fixes-test: @restart_L2_only_lacp Fixes: 5b7f8f3f7051 ('device: wait for carrier even if it wasn't us who brought the device IFF_UP') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1348
| * mptcp: merge branch 'th/mptcp-flags-changes'Thomas Haller2022-08-2511-73/+99
| |\ | | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1346
| | * glib-aux: fix nicks for zero flag in nm_utils_enum_to_str()Thomas Haller2022-08-252-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nm_utils_enum_to_str() can print flags, that is, combinations of powers of two integers. It also supports nicks, for certain flags. When we have a nick for value zero, then that requires special handling. Otherwise, that zero nick will always show up in the string representation, although, it should only be used if the enum value is exactly zero.
| | * mptcp: rework "connection.mptcp-flags" for enabling MPTCPThomas Haller2022-08-259-72/+85
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) The "enabled-on-global-iface" flag was odd. Instead, have only and "enabled" flag and skip (by default) endpoints on interface that have no default route. With the new flag "also-without-default-route", this can be overruled. So previous "enabled-on-global-default" now is the same as "enabled", and "enabled" from before behaves now like "enabled,also-without-default-route". 2) What was also odd, as that the fallback default value for the flags depends on "/proc/sys/net/mptcp/enabled". There was not one fixed fallback default, instead the used fallback value was either "enabled-on-global-iface,subflow" or "disabled". Usually that is not a problem (e.g. the default value for "ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case it is a problem, because the mptcp-flags (for better or worse) encode different things at the same time. Consider that the mptcp-flags can also have their default configured in "NetworkManager.conf", a user who wants to switch the address flags could previously do: [connection.mptcp] connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer honored. That means, MPTCP handling was always on, even if the sysctl was disabled. Now, "enabled" means that it's only enabled if the sysctl is enabled too. Now the user could write to "NetworkManager.conf" [connection.mptcp] connection.mptcp-flags=0x32 # enabled,signal,subflow and MPTCP handling would still be disabled unless the sysctl is enabled. There is now also a new flag "also-without-sysctl", so if you want to really enable MPTCP handling regardless of the sysctl, you can. The point of that might be, that we still can configure endpoints, even if kernel won't do anything with them. Then you could just flip the sysctl, and it would start working (as NetworkManager configured the endpoints already). Fixes: eb083eece5a2 ('all: add NMMptcpFlags and connection.mptcp-flags property')
| * std-aux: workaround maybe uninitialized warning with LTO on nm_ip_addr_is_null()Thomas Haller2022-08-251-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LTO without assertion enabled, thinks that certain code paths result in uninitialized code. Technically, it's not wrong, in practice those are only in cases where we already failed an assertion. In function 'nm_ip_addr_is_null', inlined from 'canonicalize_ip_binary' at src/libnm-core-impl/nm-setting-ip-config.c:67:21, inlined from 'nm_ip_route_set_next_hop_binary' at src/libnm-core-impl/nm-setting-ip-config.c:1062:23: ./src/libnm-glib-aux/nm-inet-utils.h:80:12: error: 'a' may be used uninitialized [-Werror=maybe-uninitialized] 80 | return IN6_IS_ADDR_UNSPECIFIED(&a.addr6); | ^ src/libnm-core-impl/nm-setting-ip-config.c: In function 'nm_ip_route_set_next_hop_binary': ./src/libnm-glib-aux/nm-inet-utils.h:73:14: note: 'a' declared here 73 | NMIPAddr a; | ^ Try to workaround that by letting nm_utils_addr_family_to_size() always return a non-zero size. This is ugly, because in the assertion case fail we might now also get an additional memory corruption that could have been avoided by returning zero. However, it probably doesn't matter, because in this scenario we are already in a bad situation. Fixes: b02aeaf2f3e0 ('glib-aux: fix various nm_ip_addr_*() functions for unaligned addresses')
View Lorry Controller Status