summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-29core: don't block a connection that was removedbg/rh2174353Beniamino Galvani1-1/+2
Don't try to block a device/connection pair when the connection was removed. Doing so would create a new devcon entry associated with the connection that is being deleted. Fixes: b73b34c3ee30 ('policy: track autoconnect retries per Device x Connection')
2023-03-29core: also deactivate ACs that are not authorized yetBeniamino Galvani1-0/+22
If we are deactivating active-connections for a specific settings-connection, also consider active-connections that are waiting for authorization. Otherwise, when the connection is deleted, a active-connection might still reference it.
2023-03-29core: move deactivation of active connections to the managerBeniamino Galvani3-30/+30
It's needed for the next commit.
2023-03-28dns: add support to no-aaaa optionFernando Fernandez Mancera4-7/+10
Users can set `no-aaaa` DNS option to suppress AAAA queries made by the stub resolver, including AAAA lookups triggered by NSS-based interfaces such as getaddrinfo. Only DNS lookups are affected.
2023-03-28bonding: fix verification of ns_ip6_target and arp_validate optionsFernando Fernandez Mancera1-19/+16
When arp_validate is set it requires ns_ip6_target or arp_ip_target options to be set. Fixes: c6487c240c43 ('bonding: add support to ns_ip6_target option')
2023-03-28merge: branch 'bg/hotspot-fixes'Beniamino Galvani11-42/+60
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1578
2023-03-28nmcli: increase strength of generated hotspot passwordsbg/hotspot-fixesBeniamino Galvani1-6/+6
The password currently generated has ~48 bits of entropy; increase the length from 8 to 12 to get ~70 bits. While at it, exclude characters that look similar and might be entered wrongly by users.
2023-03-28nmcli: don't set a fixed channel for wifi hotspotsBeniamino Galvani1-7/+4
Since commit f18bf17deaa5 ('wifi: cleanup ensure_hotspot_frequency()'), NetworkManager automatically selects a stable channel for AP connections that don't specify a fixed one. The advantage of this approach is that NM can select a channel that works well in the current regulatory domain. However, nmcli still sets fixed channels 1 for 2.4GHz and 7 for 5GHz when using the "device wifi hotspot". In particular, channel 7 on 5GHz seems a bad choice because according to [1] it is not usable anywhere in the world. It seems difficult to select channel that works everywhere in the 5GHz band, so it's better to not set a channel in the profile and let NM find a usable one. For consistency, do the same also for the 2.4GHz band even if the default choice (channel 1) should always work; by letting NM choose a channel, different hotspot created with nmcli have the chance of using different bands and not interfere with each other. [1] https://en.wikipedia.org/wiki/List_of_WLAN_channels
2023-03-28nmcli: fix generating hotspot passwordBeniamino Galvani1-1/+1
The generated password was all non-alphanumeric characters. Fixes: 6e96d7173168 ('all: use nm_random_*() instead of g_random_*()')
2023-03-28wifi: skip no-ir channels when determining AP channelBeniamino Galvani10-15/+23
If the automatically selected channel for an AP is set as NO-IR in the current regulatory domain, the hotspot connection will fail to start. NO-IR means that any mechanisms that initiate radiation are not permitted on this channel, this includes sending probe requests or modes of operation that require beaconing such as AP. Skip channels with the NO-IR flag.
2023-03-28platform: store attributes of wifi channelsBeniamino Galvani1-14/+27
Store attributes of wifi channels so that in a later commit we can make better decisions when selecting a channel for hotspot. Don't skip completely disabled frequencies so that the index of frequencies doesn't change and get_mesh_channel() and set_mesh_channel() get a reliable result. This was changed by mistake in 5abb1133868f ('wifi: ignore disabled frequencies '); however probably nobody is still using OLPC mesh networking at this point.
2023-03-28core: fix l3cd comparisonbg/fix-l3cd-cmpBeniamino Galvani1-26/+28
NM_CMP_SELF(a, b) returns immediately if the objects are the same. Fixes: cb29244552af ('core: support compare flags in nm_l3_config_data_cmp_full()') Fixes-test: @dracut_NM_iSCSI_ibft_table https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1583
2023-03-27core: do not check 'match' settings when comparing connectionsAlfonso Sánchez-Beato1-0/+4
Match settings are already used for matching an existing connection to a device, it does not really make sense to compare them with an auto-generated connection that is not going to have them. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1585
2023-03-27doc: replace all (allow-none) annotations by (optional) and/or (nullable)Corentin Noël70-296/+302
The (allow-none) annotation is deprecated since a long time now, it is better to use (nullable) and/or (optional) which clarifies what it means with the (out) annotation. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1551
2023-03-27libnm/docs: merge branch 'th/libnm-doc-deprecated'Thomas Haller20-749/+664
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1567
2023-03-27libnm: fix documentation for "wireless.security" propertyThomas Haller1-11/+3
This property only exists on D-Bus. Documenting it for ifcfg-rh makes no sense. Drop that part. Also reword the text about the D-Bus documentation.
2023-03-27cli: drop showing "connection.read-only" propertyThomas Haller5-689/+542
This property has no meaning. It also was only read-only. So while dropping it from the output is an API break, it hopefully does not break anybody.
2023-03-27libnm: normalize "connection.read-only" to FALSEThomas Haller2-0/+27
2023-03-27libnm: make "connection.read-only" as deprecatedThomas Haller5-7/+13
This has no more meaning, and is always false.
2023-03-27libnm: better explain wifi.seen-bssids propertyThomas Haller3-3/+8
2023-03-27cli: drop unused readonly properties "wifi.{rate,tx-power}"Thomas Haller3-20/+4
These properties were never implemented. Also, they were not settable via nmcli. Drop them from being shown. This is an API break, but hopefully something that does not affect anybody in a bad way.
2023-03-27libnm: normalize "wifi.{rate,tx-power}" properties to zeroThomas Haller3-1/+37
2023-03-27libnm: mark unused properties "wifi.{rate,tx-power}" as deprecatedThomas Haller5-17/+29
They were never implemented nor used.
2023-03-27libnm: adjust comment after "Since" annotation for NMCheckpointCreateFlagsThomas Haller1-1/+1
It's not clear what the right format for extra comments after "Since:" is. Do it like for "Deprecated:", where extra comments are common.
2023-03-27libnm: adjust "Since" annotation for @NM_DEVICE_MODEM_CAPABILITY_5GNRThomas Haller1-1/+1
We don't put such annotations in parentheses. Use uniform style.
2023-03-27libnm: fix deprecated annotationsThomas Haller6-6/+6
2023-03-27core: merge branch 'th/mtu-during-assume'Thomas Haller1-4/+3
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1576
2023-03-27device: also configure MTU while assuming devicesThomas Haller1-4/+2
The sys-iface-state "assume" means to gracefully take over a device (for example, after a restart). The end result is a fully managed interface. The flag only has meaning while activating, and for most practical purposes, such devices should be treated the same as fully activated ones. Without this, the MTU is not reset until the device reaches fully activated state, at which point the sys-iface-state switches from "assume" to "managed". With the previous commit, at that point we also schedule an idle commit, which ends up also setting the MTU. Before that, the MTU was only reset some undefined time later, when we happened to do another NML3Cfg commit. Nonetheless, even waiting until we reach fully activated state is wrong. Also during activation, commit the MTU. I guess, what theoretically could happen is that we get our MTU via ip-config (like DHCP). Then, during assuming we hit _commit_mtu() without having the DHCP lease yet. This happens after a restart, so it would be wrong to first reset the MTU, before we re-receive the DHCP lease. However, if the MTU is really to be set due via NM_DEVICE_MTU_SOURCE_IP_CONFIG, then all other MTU sources are also not in effect (because ip-config has a low priority). In that case, we would not have an MTU to reset and the code would not commit a new MTU. Thus this should still be fine, also during activation when we didn't yet get the DHCP lease (or other information to dynamically set the MTU).
2023-03-27device: schedule an idle commit when setting device's sys-iface-stateThomas Haller1-0/+1
When assuming a device, the NMActiveConnection switches the sys-iface-state from "assume" to "managed" when the device reaches the activated state. <debug> [1679353062.8884] active-connection[000055bd310b92e0]: set state activated (was activating) <debug> [1679353062.8885] active-connection[000055bd310b92e0]: update activation type from assume to managed Note that the "assume" state is probably a misfeature, and should be dropped in favor of more appropriate flags. Meaning, "assume" state for the most part is very similar to sys-iface-state "managed", and the cases where (during activation) we need to be graceful, may be better covered with other (more specialized) state flags. Regardless, for most practical purposes, sys-iface-state "assume" should be treated similar to "managed" state. When we fully activated, we should be sure to do yet another idle commit. Note that scheduling an idle-commit is something that must always be allowed to any users of NML3Cfg. The users have no knowledge about each other and coordinate by registering their commit type handles. Issuing an idle "auto" commit must be therefore allowed to them at any time. If that were not the case, then there would be a bug to fix. The only reason to maybe not do it, is when we are sure there is nothing to commit and we would want to avoid unnecessary work. You can easily reproduce this and see that we don't in fact schedule a commit after becoming managed. A commit usually only happens later, for example when we receive an autoconf6 update. This affects for example setting the MTU. Currently, _commit_mtu() bails out for nm_device_sys_iface_state_is_external_or_assume() and thus during activation the MTU will not be set. Later, once we reach activated state, due to this it still is not set right away. This patch fixes that, although we should also change _commit_mtu() to not bail out for sys-iface-state "assume".
2023-03-23libnm/connection: Fix nested hashtable documentationCorentin Noël1-25/+1
The GObject Introspection added support for using parenthesis in 1.39.0 https://bugzilla.gnome.org/show_bug.cgi?id=663190 Better use it to not collide with gtk-doc. Fixes: e0b2123c2c26 ('libnm/connection: Add missing annotations to nm_connection_diff') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1575
2023-03-23core: merge branch 'th/dbus-request-name-later'Thomas Haller3-39/+62
https://bugzilla.redhat.com/show_bug.cgi?id=2175919 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1560
2023-03-23core/dbus: "RequestName" of NetworkManager D-Bus API later to fix raceThomas Haller2-3/+8
NetworkManager.service is "Type=dbus". Systemd takes that as indication for declaring the service as started when the D-Bus name is acquired. Currently, we acquire the name very early. The benefit is, that the service appears to start very fast. However, most the D-Bus API is not yet populated or ready to use. So if you order your service `After=NetworkManager.service`, then there is a race that NetworkManager might not yet be fully usable. Another benefit was that requesting a D-Bus name is atomic. That means, we could take that to ensure only one NetworkManager daemon was running. If we noticed that NetworkManager is already running, we would quit without doing anything. In practice, systemd already ensures that the daemon is not running in parallel. This was still useful for catching misuse when testing manually. This is now no longer done. We will notice a concurrent NetworkManager only very late, at which point we might have already broken things (e.g. rewrite wrong state files). Fix the race with `After=` by acquiring the name much later. Note that NetworkManager is pretty slow during initialization. This easily adds several hundreds of milliseconds to the startup.
2023-03-23core/dbus: split RequestName D-Bus call out of initialization for NMDBusManagerThomas Haller3-42/+60
2023-03-23po/uk: update Ukrainian translationYuri Chornoivan1-1322/+1421
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1579
2023-03-23libnm: fix minor typos in documentationYuri Chornoivan4-8/+8
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1580
2023-03-23merge: branch 'lr/cloud-setup-test'Lubomir Rintel7-228/+541
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1554
2023-03-22release: bump version to 1.43.4 (development)1.43.4-devThomas Haller2-2/+2
2023-03-22core: don't configure IP routes unless there are also IP addressesThomas Haller1-1/+25
Since l3cfg rework, NetworkManager tracks IP routes early, not not only when IP configuration is ready. That means, with `ipv4.method=auto` and static `ipv4.routes`, then routes are most likely already configured before the IP address is obtained via DHCP. That may be desirable in some cases, but for many cases it's probably wrong. Instead, only configure the routes (with an ifindex) when we also have an IP address. https://bugzilla.redhat.com/show_bug.cgi?id=2102212 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1574
2023-03-22wifi: fix aggressively roaming (background Wi-Fi scanning) based on seen-bssidsThomas Haller6-11/+34
"wifi.seen-bssids" looks like a regular property, but it is not. Unlike almost all other properties, it does not contain user configuration, rather it gets filled by the daemon. The values are thus stored in "/var/lib/NetworkManager/seen-bssids" file, and the daemon maintains the values separately from the profile. Only before exporting the profile on D-Bus, the value gets merged (see NM_SETTINGS_CONNECTION_GET_PRIVATE(self)->>getsettings_cached and nm_connection_to_dbus_full(). Hence, looking at nm_setting_wireless_get_num_seen_bssids() is not working. Fix that. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1253 Fixes: 0f3203338c85 ('wifi: roam aggressively if we on a multi-AP network') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1577
2023-03-21cloud-setup: actually pass the HTTP method in nm_http_client_poll_req()lr/cloud-setup-testLubomir Rintel1-1/+2
https://bugzilla.redhat.com/show_bug.cgi?id=2179718 Fixes: 8b7e12c2d631 ('cloud-setup/ec2: start with requesting a IMDSv2 token') Fixes: cd74d7500278 ('cloud-setup: make nm_http_client_req() accept a method argument')
2023-03-21tests/client: test nm-cloud-setupLubomir Rintel4-2/+188
Some fairly rudimentary testing of nm-cloud-setup.
2023-03-21tests/client: split out nmcli specific bits into a separate cassLubomir Rintel3-217/+224
The mock service is more widely useful -- in particular for testing nm-cloud-setup in a following commit. Split the commonly useful parts into TestNmClient class.
2023-03-21tools/test-cloud-meta-mock: add a mock metadata server for cloud-setupLubomir Rintel2-0/+91
Useful for testing/development.
2023-03-21test/nm-service: short circuit activation if AC activation delay is zeroLubomir Rintel1-3/+11
This makes it possible for use to create a connection in immediately rely on it being activated.
2023-03-21test/nm-service: make activation delay actually usefulLubomir Rintel1-4/+5
The activation_state_change_delay_ms was not too useful, since it could be changed only after the AC started activating. Not a big deal, since it was actually unused. Apart from that, the SetActiveConnectionStateChangedDelay() didn't make a whole lot of sense either: it accepted a Device path, but actually was looking up an AC. Let's move the property to the Device, so that 1.) it can be adjusted before the AC is constructed (the AC will inherit it from the Device) and 2.) SetActiveConnectionStateChangedDelay() does no longer hurt my feelings.
2023-03-21test/nm-service: implement applied connection handlingLubomir Rintel1-0/+19
GetAppliedConnection() and Reapply(), both just enough to support nm-cloud-setup.
2023-03-21test/nm-service: deconstruct string properties in connections tooLubomir Rintel1-1/+1
I don't know what's going on: ====================================================================== ERROR: test_ec2 (__main__.TestNmCloudSetup.test_ec2) ---------------------------------------------------------------------- Traceback (most recent call last): File "NetworkManager/src/tests/client/test-client.py", line 2169, in f func(self) File "NetworkManager/src/tests/client/test-client.py", line 2194, in test_ec2 conn = self.srv.op_AddAndActivateConnection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "NetworkManager/src/tests/client/test-client.py", line 748, in __call__ return method(*args) ^^^^^^^^^^^^^ File "/usr/lib64/python3.11/site-packages/dbus/proxies.py", line 72, in __call__ return self._proxy_method(*args, **keywords) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/site-packages/dbus/proxies.py", line 141, in __call__ return self._connection.call_blocking(self._named_service, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/site-packages/dbus/connection.py", line 634, in call_blocking reply_message = self.send_message_with_reply_and_block( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ dbus.exceptions.DBusException: org.freedesktop.DBus.Python.Exception: Traceback (most recent call last): File "/usr/lib64/python3.11/site-packages/dbus/service.py", line 712, in _message_cb retval = candidate_method(self, *args, **keywords) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "NetworkManager/tools/test-networkmanager-service.py", line 1693, in AddAndActivateConnection conpath, acpath, result = self.AddAndActivateConnection2( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "NetworkManager/tools/test-networkmanager-service.py", line 1707, in AddAndActivateConnection2 conpath = gl.settings.AddConnection(con_hash) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "NetworkManager/tools/test-networkmanager-service.py", line 2198, in AddConnection return self.add_connection(con_hash) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "NetworkManager/tools/test-networkmanager-service.py", line 2208, in add_connection con_inst = Connection(self.c_counter, con_hash, do_verify_strict) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "NetworkManager/tools/test-networkmanager-service.py", line 2045, in __init__ NmUtil.con_hash_verify(con_hash, do_verify_strict=do_verify_strict) File "NetworkManager/tools/test-networkmanager-service.py", line 594, in con_hash_verify BusErr.raise_nmerror(e) File "NetworkManager/tools/test-networkmanager-service.py", line 497, in raise_nmerror raise e File "NetworkManager/tools/test-networkmanager-service.py", line 590, in con_hash_verify con_nm = NmUtil.con_hash_to_connection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "NetworkManager/tools/test-networkmanager-service.py", line 537, in con_hash_to_connection assert GLib.Variant.equal(x_con, Util.variant_from_dbus(con_hash)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "NetworkManager/tools/test-networkmanager-service.py", line 378, in variant_from_dbus raise Exception("Unsupported type for value '%s'" % (repr(val))) Exception: Unsupported type for value 'dbus.Dictionary({ dbus.String('connection'): dbus.Dictionary({ dbus.String('type'): dbus.String('802-3-ethernet'), dbus.String('id'): dbus.String('con-eth0'), 'uuid': '5fcfd6d7-1e63-3332-8826-a7eda103792d' }, signature=dbus.Signature('ss')), dbus.String('ipv4'): dbus.Dictionary({ dbus.String('method'): dbus.String('auto') }, signature=dbus.Signature('ss')) }, signature=dbus.Signature('sa{ss}'))'
2023-03-21glib-aux/prioq: remove unused includesThomas Haller1-3/+0
2023-03-21platform,core: merge branch 'th/platform-rt-prefsrc'Thomas Haller21-630/+1474
https://bugzilla.redhat.com/show_bug.cgi?id=2046293 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1550
2023-03-21platform: rework handling of failed routes during nm_platform_ip_route_sync()Thomas Haller5-315/+305
Previously, there was "temporary-not-available" mechanism in NML3Cfg, which aimed to handle IPv6 routes with prefsrc. Theoretically, that mechanism may have been extended to other use-cases, like IPv4 routes with prefsrc. What it attempted to handle, is the inability to configure such routes, unless the respective prefsrc address is configured and non-tentative. However, the address that we are waiting for, could also be on another interface, so that mechanism wasn't applicable. This is now replaced by _routes_watch_ip_addrs(). It seems there isn't anything useful left for the "temporary-not-available" mechanism and it can go, except... We want to log a warning when we are unable to configure a route. Also, in the future we might want to know when the IP configuration is degradated due to inability to configure the desired routes (a condition that we might want to expose to the user, not only via logging; or we may want to react on that). However, with prefsrc routes we don't know right away whether the inability to configure the route right away indicates an actual problem, or whether that will resolve itself (e.g. after the address passes DAD/ACD, after we received an DHCP lease or after the address was configured on another interface). Consequently, to know whether the current inability to configure such a route is a problem, we need to know the larger context. nm_platform_ip_route_sync() does not have that context. Instead, nm_platform_ip_route_sync() needs only do debug log about failure to configure routes. It will now also return all the failed routes to NML3Cfg, which can decide whether that is a problem. This reworks the previous "temporary-not-available" mechanism to track the state of the failed routes, to eventually decide whether there is an actual problem (and log about it). Another problem this solves is that since commit ('platform: always reconfigure IP routes even if removed externally'), we will eagerly re-try to configure the same route over and over. We cannot just spam the log with warnings about the same failure on every commit. We need to remember that we already logged about the problem and rate limit warnings otherwise. This is what the new mechanism also achieves. Indeed, all this is mostly for the sole benefit of logging better warnings (and not duplicated).
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-14 04:03:54 +0000