summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * dispatcher: clarify documentation about first argument to dispatcher scripts ↵Thomas Haller2020-04-302-3/+7
|/ | | | | | | | | | | | | for "connectivity-change" The manual page claimed that for "connectivitiy-change" actions, the dispatcher scripts would get as first argument (the device name) "none". That was not done, only for "hostname" actions. For consistency, maybe that should be adjusted to also pass "none" for connectivity change events. However, "none" is really an odd value, if there is no device. Passing an empty word is IMO nicer. So stick to that behavior, despite being inconsistent. Also fix the documentation about that.
* nm-online: allow configuring timeout via NM_ONLINE_TIMEOUT environmentThomas Haller2020-04-305-5/+30
| | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1828458 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/484
* n-dhcp4: don't fail dispatch in case of receive errorsBeniamino Galvani2020-04-302-8/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently any error encountered in n_dhcp4_c_connection_dispatch_io() causes a dispatch failure and interrupts the library state machine. The recvmsg() on the socket can fail for different reasons; one of these is for example that the UDP request previously sent got a ICMP port-unreachable response. This can be reproduced in the following way: ip netns add ns1 ip link add veth0 type veth peer name veth1 ip link set veth1 netns ns1 ip link set veth0 up cat > dhcpd.conf <<EOF server-identifier 172.25.0.1; max-lease-time 120; default-lease-time 120; subnet 172.25.0.0 netmask 255.255.255.0 { range 172.25.0.100 172.25.0.200; } EOF ip -n ns1 link set veth1 up ip -n ns1 address add dev veth1 172.25.0.1/24 ip netns exec ns1 iptables -A INPUT -p udp --dport 67 -j REJECT ip netns exec ns1 dhcpd -4 -cf dhcpd.conf -pf /tmp/dhcp-server.pid If a client is started on veth0, it is able to obtain a lease despite the firewall rule blocking DHCP, because dhcpd uses a packet socket. Then it fails during the renewal because the recvmsg() fails: dhcp4 (veth0): send REQUEST of 172.25.0.178 to 172.25.0.1 dhcp4 (veth0): error -111 dispatching events dhcp4 (veth0): state changed bound -> fail The client should consider such errors non fatal and keep running. https://bugzilla.redhat.com/show_bug.cgi?id=1829178 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/486
* keyfile: don't declare keyfile getters/setter functions with macroThomas Haller2020-04-301-40/+21
| | | | | | In general, I like macros. But in this case it seems the make the code harder to understand than it needs to be. There are repeated patterns in these declarations, but I feel they are better recognizible by aligning the lines nicely.
* bus-manager/dhcp: don't log pointer values directlyThomas Haller2020-04-301-2/+6
| | | | | Direct pointer values can be used to circumvent ASLR. Obfuscate the pointer values.
* dhcp: cleanup build_signal_parameters() in nm-dhcp-helperThomas Haller2020-04-301-17/+30
| | | | | | Also, silently ignore all environment variables with a name that is not valid UTF-8. We would hit an assertion trying to put that in a GVariant (or sending it via D-Bus).
* wifi: clear scan_request_ssids_hash if not neededThomas Haller2020-04-301-17/+30
| | | | | It is very uncommon that a user provides explicit SSIDs to scan. So, most of the time there is nothing to do here.
* wifi: don't unnecessarily trim tracked ssid listThomas Haller2020-04-301-7/+5
| | | | | | Only _scan_request_ssids_track() adds elements to the list, and that already trims the list to a maxium length. In all other cases, we never expect a need to trim the list.
* wifi: pass now_msec to _scan_request_ssids_fetch()Thomas Haller2020-04-301-4/+5
| | | | | We make decisions based on the timestamp. We should only fetch the timestamp once, and make consistent decisions about that. Don't read different timestamps.
* wifi: fix trimming list of tracked ssids to scanThomas Haller2020-04-301-1/+1
| | | | Fixes: e07fc217ecd7 ('wifi: rework scanning of Wi-Fi device')
* wifi: really fix crash during dispose of NMDeviceWifiThomas Haller2020-04-301-1/+6
| | | | | | | | | | | | | | | | | | | | | | The right fix is to return from _scan_kickoff() right away. Backtrace: #0 0x00007f520eeb2002 g_logv (libglib-2.0.so.0 + 0x5a002) #1 0x00007f520eeb2273 g_log (libglib-2.0.so.0 + 0x5a273) #2 0x000056026929b25a nm_supplicant_interface_get_max_scan_ssids (NetworkManager + 0x27e25a) #3 0x00007f520c238bb1 _scan_request_ssids_build_hidden (libnm-device-plugin-wifi.so + 0x15bb1) #4 0x00007f520c23a2d5 _scan_notify_is_scanning (libnm-device-plugin-wifi.so + 0x172d5) #5 0x00007f520c2433d3 dispose (libnm-device-plugin-wifi.so + 0x203d3) #6 0x00007f520efa3c78 g_object_unref (libgobject-2.0.so.0 + 0x18c78) #7 0x00005602690ada1a remove_device (NetworkManager + 0x90a1a) #8 0x00005602690be428 nm_manager_stop (NetworkManager + 0xa1428) #9 0x0000560269064adb main (NetworkManager + 0x47adb) #10 0x00007f520ec70042 __libc_start_main (libc.so.6 + 0x27042) #11 0x0000560269064efe _start (NetworkManager + 0x47efe) Fixes: e07fc217ecd7 ('wifi: rework scanning of Wi-Fi device') Fixes: a2deb0da5ef9 ('wifi: fix crash during dispose of NMDeviceWifi')
* wifi: fix crash during dispose of NMDeviceWifiThomas Haller2020-04-291-1/+1
| | | | | | | | | | | | | | | | | | | Backtrace: #0 0x00007f520eeb2002 g_logv (libglib-2.0.so.0 + 0x5a002) #1 0x00007f520eeb2273 g_log (libglib-2.0.so.0 + 0x5a273) #2 0x000056026929b25a nm_supplicant_interface_get_max_scan_ssids (NetworkManager + 0x27e25a) #3 0x00007f520c238bb1 _scan_request_ssids_build_hidden (libnm-device-plugin-wifi.so + 0x15bb1) #4 0x00007f520c23a2d5 _scan_notify_is_scanning (libnm-device-plugin-wifi.so + 0x172d5) #5 0x00007f520c2433d3 dispose (libnm-device-plugin-wifi.so + 0x203d3) #6 0x00007f520efa3c78 g_object_unref (libgobject-2.0.so.0 + 0x18c78) #7 0x00005602690ada1a remove_device (NetworkManager + 0x90a1a) #8 0x00005602690be428 nm_manager_stop (NetworkManager + 0xa1428) #9 0x0000560269064adb main (NetworkManager + 0x47adb) #10 0x00007f520ec70042 __libc_start_main (libc.so.6 + 0x27042) #11 0x0000560269064efe _start (NetworkManager + 0x47efe) Fixes: e07fc217ecd7 ('wifi: rework scanning of Wi-Fi device')
* clients/trivial: rename VpnPasswordName struct to have NM prefixThomas Haller2020-04-293-6/+6
|
* clients: define VPN password list closer to where it is used in ↵Thomas Haller2020-04-293-39/+49
| | | | nm_vpn_get_secret_names()
* clients: cleanup nm_vpn_get_secret_names() to use NM_IN_STRSET()Thomas Haller2020-04-291-12/+12
|
* wifi: reduce scan rate limiting while not being activatedThomas Haller2020-04-291-20/+32
| | | | | | | | | | While we are not activated, there is less need to rate limit the scan requests to 8 seconds. Only rate limit the requests for 1.5 seconds in that case. Also, when changing the MAC address, supplicant flushes the AP list. We should be able to scan right away. Reset the counters for the rate limiting and periodic scanning.
* wifi: merge branch 'th/wifi-scan' (part 2)Thomas Haller2020-04-292-347/+595
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/479
| * wifi: don't limit active scans for SSIDs to 5Thomas Haller2020-04-292-27/+55
| | | | | | | | | | | | | | | | | | | | As far as NMSupplicantInterface is concerned, don't clamp the max-scan-ssids to 5. We should track the real value that wpa_supplicant announces, and it's up to the caller to provide fewer SSIDs. In particular, we want to limit the number of hidden SSIDs that we accept from connection profiles, but we don't want to limit the number of active scans via `nmcli device wifi rescan ssid $SSID [...]`.
| * wifi: rework scanning of Wi-Fi deviceThomas Haller2020-04-291-322/+542
|/ | | | | | | | | | | | | | | | | | | | | | | Handling the scanning is complicated. - we want to have periodic scans. But only at certain times, and with an increasing back off timeout. - the user can initiate explicit scans via D-Bus. Thereby a list of SSIDs scan be provided. - if there are any hidden Wi-Fi profiles configured, we want to explicitly scan for their SSIDs. - explicit scans are not possible at any time. But we should not reject the scan request, but instead remember to scan later, when possible. This is a heavy rework. It also aims to fix issues of scanning since the recent rework of supplicant handling in commit b83f07916a54 ('supplicant: large rework of wpa_supplicant handling') that can render Wi-Fi scanning broken. Fixes: b83f07916a54 ('supplicant: large rework of wpa_supplicant handling'):
* wifi/iwd: merge branch 'andhe:iwd-connect-hidden'Thomas Haller2020-04-291-16/+43
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/285
| * iwd: use ConnectHiddenNetwork to provision hidden networkAndreas Henriksson2020-04-291-1/+24
| | | | | | | | | | | | | | | | | | | | The Station.ConnectHiddenNetwork will provision a network in the iwd known-networks list. This should allow us to later use the Network.Connect interface to connect in the future. (Note: Attempts to use Station.ConnectHiddenNetwork on already provisioned networks, i.e. networks iwd knows about, will fail.) This commit squashed several fixups made by thaller.
| * iwd: support connecting to hidden networksAndreas Henriksson2020-04-291-15/+19
|/ | | | | | | | | | | | | | | | Newer versions of iwd has supported connecting to hidden networks for a while now. There's a separate "connect-hidden" command in iwctl that needs to be used instead of the regular "connect" command. The equivalent on dbus is to use ConnectHiddenNetwork instead of Connect on the Station interface. NetworkManager however uses the Network interface and given we the explicit SSID usage we can connect to hidden networks with that. This change disabled the explicit check that disallows even attempting hidden networks when using iwd. This has been tested to work with a previously known hidden network. Tests connecting to a previously unknown network has failed.
* wifi: merge branch 'th/wifi-scan' (part 1)Thomas Haller2020-04-2816-184/+427
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/479
| * wifi: express SCAN_RAND_MAC_ADDRESS_EXPIRE time in secondsThomas Haller2020-04-281-2/+2
| | | | | | | | | | We commonly use already seconds and milliseconds scales for computing timeouts. Reduce the number of difference scales and don't also use minutes.
| * supplicant: log changes to max-scan-ssids of NMSupplicantInterfaceThomas Haller2020-04-281-3/+8
| |
| * device: implement "auth-request" as async operation ↵Thomas Haller2020-04-288-105/+183
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nm_manager_device_auth_request() GObject signals only complicate the code and are less efficient. Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous request. Of course, fundamentally emitting a signal *is* the same as calling a method. However, implementing this as signal is really not nice nor best practice. For one, there is a (negligible) overhead emitting a GObject signal. But what is worse, GObject signals are not as strongly typed and make it harder to understand what happens. The signal had the appearance of providing some special decoupling of NMDevice and NMManager. Of course, in practice, they were not more decoupled (both forms are the same in nature), but it was harder to understand how they work together. Add and call a method nm_manager_device_auth_request() instead. This has the notion of invoking an asynchronous method. Also, never invoke the callback synchronously and provide a cancellable. Like every asynchronous operation, it *must* be cancellable, and callers should make sure to provide a mechanism to abort.
| * auth: track NMAuthChain data in array instead of CListThomas Haller2020-04-281-45/+43
| | | | | | | | | | | | It's about as complicated to track a CList as it is to track an allocated array. The latter requires fewer allocations and has better locality. That makes it preferable.
| * auth: natively support GCancellable in NMAuthChainThomas Haller2020-04-282-28/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want that our asynchronous operations are cancellable. In fact, NMAuthChain is already (manually) cancellable by the user calling nm_auth_chain_destroy(). However, sometimes we have a GCancellable at hand, so the callers would have to register to the cancellable themselves. Instead, support setting a cancellable to the NMAuthChain, that aborts the request and invokes the callback. It does so always on an idle handler. Also, the user may only set the cancellable once, and only before starting the first call.
| * device: add nm_device_get_manager()Thomas Haller2020-04-282-1/+11
| | | | | | | | | | | | | | | | | | | | NMDevice already has access to the NMSettings singleton. It is permissible that NMDevice *knows* about NMManager. The current alternative is emitting GObject signals like NM_DEVICE_AUTH_REQUEST, pretending that NMDevice and NMManager would be completely independent, or that there could be anybody else handling the request aside NMManager. No, NMManager and NMDevice may know each other and refer to each other. Just like NMDevice also knows and refers to NMSettings.
| * shared/glib: prevent users to use g_cancellable_reset()Thomas Haller2020-04-281-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When handling a GCancellable, you make decisions based on when the cancelled property of a GCancellable changes. Correctly handling a cancellable becoming uncancelled again is really complicated, nor is it clear what it even means: should the flipping be treated as cancellation or not? Probably if the cancelled property gets reset, you already start aborting and there is no way back. So, you would want that a cancellation is always handled. But it's hard to implement that correctly, and it's odd to claim something was cancelled, if g_cancellable_is_cancelled() doesn't agree (anymore). Avoid such problems by preventing users to call g_cancellable_reset().
| * shared: add nm_gbytes_get_empty() singleton getterThomas Haller2020-04-282-0/+20
| |
| * shared: add nm_gbytes_hash() and nm_gbytes_equal()Thomas Haller2020-04-282-0/+14
|/
* libnm/doc: fix spelling in nm_client_add_and_activate_connection2() ↵Thomas Haller2020-04-281-3/+3
| | | | documentation
* all: merge branch 'th/mud-url-global-default'Thomas Haller2020-04-2812-679/+627
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/477
| * cli: hide default setting of "connection.mud-url" from nmcli outputth/mud-url-global-defaultThomas Haller2020-04-284-654/+517
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "connection.mud-url" is a commonly not used parameter, that most users won't care. To minimize the output of $ nmcli connection show "$PROFILE" hide the MUD URL if it is unset. This mechanism of nmcli is not yet great, because there is currently no way to print a default value, and $ nmcli -f connection.mud-url connection show "$PROFILE" does not work as one would expect(??). But that is a shortcoming of the general mechanism in nmcli, and not specific to the MUD URL property.
| * dhcp: make connection.mud-url configurable as global connection defaultThomas Haller2020-04-287-17/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conceptionally, the MUD URL really depends on the device, and not so much the connection profile. That is, when you have a specific IoT device, then this device probably should use the same MUD URL for all profiles (at least by default). We already have a mechanism for that: global connection defaults. Use that. This allows a vendor drop pre-install a file "/usr/lib/NetworkManager/conf.d/10-mud-url.conf" with [connection-10-mud-url] connection.mud-url=https://example.com Note that we introduce the special "connection.mud-url" value "none", to indicate not to use a MUD URL (but also not to consult the global connection default).
| * cli: handle string properties that can both be empty and %NULLThomas Haller2020-04-282-8/+43
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default value of a string property (almost?) always should be %NULL, which means the value is absent and not specified. That is necessary because adding new properties must be backward compatible. That means, after upgrade those properties will have their value unset. In these cases, %NULL really translates to some property dependant behavior (like not using the value, or using a special default value). For example leaving "ethernet.cloned-mac-address" unset really means "preserve", with the twist that %NULL can be overridden by a global connection default. For most string properties, a value can only be unset (%NULL) or set to a non-empty string. nm_connection_verify() enforces that. However, for some properties, it makes sense to allow both unset and the empty word "" as value. This is the case if a property can have it's value overridden by a global connection default, or if we need the differentiation between having a value unset and having it set to the empty word. We would usually avoid allowing the empty word beside %NULL, because that makes it hard to express the difference on the command line of nmcli or in a UI text entry field. In the "ethernet.cloned-mac-address" example, "" is not necessary nor sensible. However, for some properties really all string values may be possible (including "") and also unset/%NULL. Then, we need some form of escaping/mangling, to allow to express all possible values. The chosen style here is that on nmcli input field "" means %NULL, while a word with all white space stands for the word with one less white space characters. This is still unused, but I think it makes sense for some properties. I initially added this for "connection.mud-url", but a valid MUD-URL always must start with "https://", so not all strings are possible to begin with. So to explicitly express that no MUD-URL should be set, we will instead introduce a special word "none", and not use the empty word, due to the oddities discussed here. However, I think this may well make sense for some properties where all strings are valid.
* device: flush IP configuration of slaves during activationBeniamino Galvani2020-04-281-12/+31
| | | | | | | | | | | | | | If a device only has an IPv6 link-local address, we don't generate an assumed connection. Therefore, when a new slave connection (without IP configuration) is activated on the device, we don't deactivate any existing connection and the link-local address remains configured. The IP configuration of an activated slave should be predictable and not depend on the previous state; let's flush addresses and routes on activation. https://bugzilla.redhat.com/show_bug.cgi?id=1816517 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/480
* vpn: merge branch 'th/vpn-ipv6-addr-fix-assert'Thomas Haller2020-04-281-14/+26
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/482
| * vpn: cleanup loop in nm_vpn_connection_ip6_config_get()Thomas Haller2020-04-281-14/+24
| | | | | | | | | | | | I find it simpler to follow the pattern of checking conditions and "erroring out", by going to the next entry. The entire loop already behaves like that.
| * vpn: clear host part of IPv6 routes received from VPN pluginThomas Haller2020-04-281-0/+2
|/ | | | | | | | | | | | | Kernel would reject adding a route with a destination host part not all zero. NetworkManager generally coerces such routes and there are assertions in place to ensure that. We forgot to ensure that for certain IPv6 routes from VPN plugins. This can cause an assertion failure and wrong behavior. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/425 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/482
* examples: add Wi-Fi P2P exampleBeniamino Galvani2020-04-271-0/+109
| | | | | Add a python example using GObject introspection that shows how to scan for Wi-Fi P2P peers and connect to one of them.
* libnm,dhcp: use nm_clear_g_free() instead of nm_clear_pointer(, g_free)Thomas Haller2020-04-272-2/+2
|
* libnm/doc: clarify use of "ipv[46].gateway in nm-settings manualThomas Haller2020-04-262-4/+8
|
* libnm/meson.build: stop using env -i (just env)Michael Stapelberg2020-04-261-1/+1
| | | | | | | | | | env -i starts with an empty environment, which is undesired when the build environment needs certain environment variables to function. One such example is a custom PYTHONPATH, which gets dropped by env -i and results in the nm-settings-docs.xml generator not finding the gi Python module. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/478
* dhcp: enforce MUD URL to use "https://" schemeThomas Haller2020-04-243-14/+19
| | | | | | | | | | | | nm_sd_http_url_is_valid_https() is rather clunky, but it is this way, because we must not disagree with systemd code about what makes a valid URL. RFC 8520 says "MUD URLs MUST use the "https" scheme". See-also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/463#note_476190 Fixes: cedcea5ee812 ('libnm: fix verification of connection:mud-url property')
* wifi: merge branch 'th/cli-trigger-scan-retry'Thomas Haller2020-04-2412-76/+253
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/476
| * wifi: add callback to nm_supplicant_interface_request_scan()th/cli-trigger-scan-retryThomas Haller2020-04-243-17/+90
| | | | | | | | | | | | | | | | | | While we request a scan, we are not yet actually scanning. That means, the supplicant's "scanning" property will only change to TRUE a while after we initiate the scan. It may even never happen. We thus need to handle that the request is currently pending and react when the request completes.
| * wifi: add more trace logging to supplicant interfaceThomas Haller2020-04-241-4/+13
| |
| * cli: repeatedly trigger Wi-Fi scans while waiting for scan resultThomas Haller2020-04-241-7/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NetworkManager will reject scan requests, if it is currently scanning. That is very wrong. Even if NetworkManager wants to ratelimit scan requests or not scan at critical moments, it should never reject a request, but remember and start scanning as soon as it can. That should be fixed. But regardless, also nmcli can do better. If you issue $ nmcli device wifi list --rescan yes once, it works as expected. If you issue it again right after, the scan request of nmcli will be rejected. But nmcli cannot just merely complete and print the result. Instead, it will wait in the hope that a scan result will be present soon. But if the request was simply rejected, then the result will never come, and nmcli hangs for the 15 seconds timeout. Instead, repeatedly re-trigger scan requests, in the hope that as soon as possible we will be ready.
View Lorry Controller Status