summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-30wwan/ofono: account for port in the Proxy propertyRatchanan Srirattanamet1-2/+11
2023-03-30wwan/ofono: correct MMS proxy property lookupRatchanan Srirattanamet1-3/+3
The property name under `Settings` dict is just `Proxy`, unlike the one outside which is `MessageProxy`. See [1]. [1] https://kernel.googlesource.com/pub/scm/network/ofono/ofono/+/refs/heads/master/doc/connman-api.txt#253 Fixes: a6e81af87f18 ('wwan: add support for using oFono as a modem manager')
2023-03-30platform: merge branch 'lr/nl-retry'Thomas Haller1-127/+195
https://bugzilla.redhat.com/show_bug.cgi?id=2169512 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1537
2023-03-29platform: explicitly compare seq_result number against ↵Thomas Haller1-10/+10
WAIT_FOR_NL_RESPONSE_RESULT_UNKNOWN We have other places like nm_assert(!out_seq_result || *out_seq_result == WAIT_FOR_NL_RESPONSE_RESULT_UNKNOWN); where we explicitly compare against WAIT_FOR_NL_RESPONSE_RESULT_UNKNOWN. Do that here too.
2023-03-29platform: always retry when netlink drops messagesLubomir Rintel1-120/+175
Netlink is capable of dropping not only outbout messages, but also the requests. We should always try to recover from those.
2023-03-29platform: increase log level for some failuresLubomir Rintel1-2/+2
These are not expected to happen. While probably harmless, we should notice when they do.
2023-03-29platform: limit retry count on link changeLubomir Rintel1-1/+2
This is a nice safeguard, also consistent with ip_route_get().
2023-03-29platform: increase netlink resync retry countLubomir Rintel1-1/+1
With a small buffer (of 4K) and many links (100 ethernet adapters), I've seen up to ~15 retries of link change until things settled. Let's increase this. Still a »bulharská konštanta« but possibly safer and more broadly useful (so we can cap the link change retry count too).
2023-03-29platform: create a define for retry count when netlink drops dataLubomir Rintel1-1/+6
We're going to use it elsewhere.
2023-03-29platform: assert the seq_status is known to be unknown on sending a nl messageLubomir Rintel1-0/+6
This guards against accidental use of a stale result.
2023-03-29platform: reset seq_result on retrying link changeLubomir Rintel1-1/+2
Shouldn't make a difference at this point. It's nevertheless a good practice to guard against accidental use of a stale result.
2023-03-29libnm,doc: merge branch 'th/gtkdoc-annotations-cleanup'Thomas Haller14-55/+62
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1587
2023-03-29doc: reorder gtkdoc annotations for consistencyThomas Haller6-12/+12
2023-03-29doc: use "Returns:" annotation instead of deprecated aliasesThomas Haller8-23/+23
2023-03-29all: various fixes to gtk-doc annotationsThomas Haller4-20/+26
- drop annotations from "@error" which has defaults. - ensure all annotations are on the same line. That's useful when searching for an annotation, to find the line that specifies the argument name. - convert a few plain docs into gtkdoc annotations.
2023-03-29checkpatch: discourage deprecated "(allow-none)" annotationThomas Haller1-0/+1
2023-03-29merge: branch 'bg/rh2174353'Beniamino Galvani3-31/+54
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1589 https://bugzilla.redhat.com/show_bug.cgi?id=2174353
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
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-09 05:08:31 +0000