summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* dns: add support to no-aaaa optionff/no-aaaaFernando Fernandez Mancera2023-03-284-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.
* bonding: fix verification of ns_ip6_target and arp_validate optionsFernando Fernandez Mancera2023-03-281-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')
* merge: branch 'bg/hotspot-fixes'Beniamino Galvani2023-03-2811-42/+60
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1578
| * nmcli: increase strength of generated hotspot passwordsbg/hotspot-fixesBeniamino Galvani2023-03-281-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.
| * nmcli: don't set a fixed channel for wifi hotspotsBeniamino Galvani2023-03-281-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
| * nmcli: fix generating hotspot passwordBeniamino Galvani2023-03-281-1/+1
| | | | | | | | | | | | The generated password was all non-alphanumeric characters. Fixes: 6e96d7173168 ('all: use nm_random_*() instead of g_random_*()')
| * wifi: skip no-ir channels when determining AP channelBeniamino Galvani2023-03-2810-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.
| * platform: store attributes of wifi channelsBeniamino Galvani2023-03-281-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.
* core: fix l3cd comparisonbg/fix-l3cd-cmpBeniamino Galvani2023-03-281-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
* core: do not check 'match' settings when comparing connectionsAlfonso Sánchez-Beato2023-03-271-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
* doc: replace all (allow-none) annotations by (optional) and/or (nullable)Corentin Noël2023-03-2770-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
* libnm/docs: merge branch 'th/libnm-doc-deprecated'Thomas Haller2023-03-2720-749/+664
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1567
| * libnm: fix documentation for "wireless.security" propertyThomas Haller2023-03-271-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.
| * cli: drop showing "connection.read-only" propertyThomas Haller2023-03-275-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.
| * libnm: normalize "connection.read-only" to FALSEThomas Haller2023-03-272-0/+27
| |
| * libnm: make "connection.read-only" as deprecatedThomas Haller2023-03-275-7/+13
| | | | | | | | This has no more meaning, and is always false.
| * libnm: better explain wifi.seen-bssids propertyThomas Haller2023-03-273-3/+8
| |
| * cli: drop unused readonly properties "wifi.{rate,tx-power}"Thomas Haller2023-03-273-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.
| * libnm: normalize "wifi.{rate,tx-power}" properties to zeroThomas Haller2023-03-273-1/+37
| |
| * libnm: mark unused properties "wifi.{rate,tx-power}" as deprecatedThomas Haller2023-03-275-17/+29
| | | | | | | | They were never implemented nor used.
| * libnm: adjust comment after "Since" annotation for NMCheckpointCreateFlagsThomas Haller2023-03-271-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.
| * libnm: adjust "Since" annotation for @NM_DEVICE_MODEM_CAPABILITY_5GNRThomas Haller2023-03-271-1/+1
| | | | | | | | We don't put such annotations in parentheses. Use uniform style.
| * libnm: fix deprecated annotationsThomas Haller2023-03-276-6/+6
|/
* core: merge branch 'th/mtu-during-assume'Thomas Haller2023-03-271-4/+3
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1576
| * device: also configure MTU while assuming devicesThomas Haller2023-03-271-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).
| * device: schedule an idle commit when setting device's sys-iface-stateThomas Haller2023-03-271-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".
* libnm/connection: Fix nested hashtable documentationCorentin Noël2023-03-231-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
* core: merge branch 'th/dbus-request-name-later'Thomas Haller2023-03-233-39/+62
|\ | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=2175919 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1560
| * core/dbus: "RequestName" of NetworkManager D-Bus API later to fix raceThomas Haller2023-03-232-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.
| * core/dbus: split RequestName D-Bus call out of initialization for NMDBusManagerThomas Haller2023-03-233-42/+60
|/
* po/uk: update Ukrainian translationYuri Chornoivan2023-03-231-1322/+1421
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1579
* libnm: fix minor typos in documentationYuri Chornoivan2023-03-234-8/+8
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1580
* merge: branch 'lr/cloud-setup-test'Lubomir Rintel2023-03-237-228/+541
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1554
| * cloud-setup: actually pass the HTTP method in nm_http_client_poll_req()lr/cloud-setup-testLubomir Rintel2023-03-211-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')
| * tests/client: test nm-cloud-setupLubomir Rintel2023-03-214-2/+188
| | | | | | | | Some fairly rudimentary testing of nm-cloud-setup.
| * tests/client: split out nmcli specific bits into a separate cassLubomir Rintel2023-03-213-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.
| * tools/test-cloud-meta-mock: add a mock metadata server for cloud-setupLubomir Rintel2023-03-212-0/+91
| | | | | | | | Useful for testing/development.
| * test/nm-service: short circuit activation if AC activation delay is zeroLubomir Rintel2023-03-211-3/+11
| | | | | | | | | | This makes it possible for use to create a connection in immediately rely on it being activated.
| * test/nm-service: make activation delay actually usefulLubomir Rintel2023-03-211-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.
| * test/nm-service: implement applied connection handlingLubomir Rintel2023-03-211-0/+19
| | | | | | | | | | GetAppliedConnection() and Reapply(), both just enough to support nm-cloud-setup.
| * test/nm-service: deconstruct string properties in connections tooLubomir Rintel2023-03-211-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}'))'
* | release: bump version to 1.43.4 (development)1.43.4-devThomas Haller2023-03-222-2/+2
| |
* | core: don't configure IP routes unless there are also IP addressesThomas Haller2023-03-221-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
* | wifi: fix aggressively roaming (background Wi-Fi scanning) based on seen-bssidsThomas Haller2023-03-226-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
* glib-aux/prioq: remove unused includesThomas Haller2023-03-211-3/+0
|
* platform,core: merge branch 'th/platform-rt-prefsrc'Thomas Haller2023-03-2121-630/+1474
|\ | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=2046293 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1550
| * platform: rework handling of failed routes during nm_platform_ip_route_sync()Thomas Haller2023-03-215-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).
| * l3cfg: don't return success/failure from _l3_commit_one()Thomas Haller2023-03-211-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It was unused anyway. But also, what would we do with this? We are in the middle of a commit, if something goes wrong, we cannot just abort but need to continue on and make the best of it. Maybe there are very specific error cases that we need to handle, but those are not covered by a boolean return value. Instead, we might need to take specific action. The boolean success variable was meaningless. Drop it.
| * platform: log extack_msg for failures in nm_platform_ip_route_sync()Thomas Haller2023-03-211-5/+8
| |
| * platform: cleanup error handling in nm_platform_ip_route_sync()Thomas Haller2023-03-211-63/+57
| | | | | | | | Unindent the if-else blocks.
View Lorry Controller Status