summaryrefslogtreecommitdiff
path: root/clients
Commit message (Collapse)AuthorAgeFilesLines
* all: avoid (soon to be) deprecated API instead of nm_setting_option*()Thomas Haller2020-05-221-93/+57
|
* clients: add support for ethtool ring settingsAntonio Cardace2020-05-201-8/+33
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1614700
* cli: support dns-search for import of WireGuard profilesThomas Haller2020-05-191-17/+29
| | | | | | | | wg-quick now supports specifying DNS searches as part of DNS= setting. See-also: https://lists.zx2c4.com/pipermail/wireguard/2020-May/005415.html See-also: https://git.zx2c4.com/wireguard-tools/commit/?id=7f236c79570642d466c5acab890b26c3a07f4f7a
* nmtui: show error on connection deactivation failureOlivier Gayot2020-05-151-1/+12
| | | | | | | | | | | When a failure occurs on deactivation of a connection, no error was shown on the TUI client. It was not obvious if anything was actually happening after pressing the <Deactivate> button. This patch shows the error in a dialog just like we do when a failure occurs on activation of a connection. https://mail.gnome.org/archives/networkmanager-list/2020-May/msg00004.html
* cli: let nmcli remove individual coalesce settingsAntonio Cardace2020-05-141-0/+7
| | | | | | | Remove coalesce settings by setting them to NULL. eg: $ nmcli c mod $conn ethtool.$coalesce-setting ''
* clients/tests: set "UBSAN_OPTIONS" to abort tests and set ↵Thomas Haller2020-05-141-2/+3
| | | | "ASAN_OPTIONS=detect_leaks=1"
* clients/tests: preserve caller's ASAN/LSAN/UBSAN environment variables for ↵Thomas Haller2020-05-141-1/+18
| | | | client tests
* cli: use nm_strdup_int() in "clients/cli/devices.c"Thomas Haller2020-05-141-7/+7
|
* cli: fix leak in show_device_lldp_list() for nmc_parse_lldp_capabilities()Thomas Haller2020-05-141-2/+5
|
* cli: fix leak in show_device_lldp_list()Thomas Haller2020-05-141-2/+2
|
* cli: fix memcpy() with %NULL pointers in nmc_get_devices_sorted()Thomas Haller2020-05-141-1/+2
| | | | | | UBSan correctly flags this: clients/cli/devices.c:966:2: runtime error: null pointer passed as argument 2, which is declared to never be null
* cli: cleanup internal functions in "clients/cli/connections.c"Thomas Haller2020-05-131-60/+49
| | | | There should be no change in behavior. Use cleanup attribute.
* cli: use cleanup attribute in save_history_cmds()Thomas Haller2020-05-131-37/+32
|
* cli/tests: add unit test for nmc_utils_parse_passwd_file()Thomas Haller2020-05-131-0/+73
|
* cli: split parsing from nmc_utils_read_passwd_file()Thomas Haller2020-05-132-7/+22
| | | | Makes it easier testable.
* cli: move nmc_utils_read_passwd_file() to "common/nm-client-utils.c"Thomas Haller2020-05-133-180/+184
|
* cli: refactor error handling in parse_passwords()Thomas Haller2020-05-131-26/+53
|
* cli: support backslash escaping in passwd-fileThomas Haller2020-05-131-34/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rework parsing of nmcli's passwd-file. 1) support backslash escaping of secrets. - only the secret can be backslash escaped, the property and setting name cannot. This is a change in behavior for passwd-files with secrets that contain a backslash. 2) strip the white space around the secret. This is a change in behavior for secrets that had leading or trailing spaces. Note that you can backslash escape spaces in secrets. 3) strip white space around the setting.property key. This is also a change in behavior, but such keys would never have been valid previously (or the caller would have performed the same kind of stripping). 4) accept '=' as alternative delimiter beside ':'. The ':' feels really odd and unexpected. Also accept '='. This is a change in behavior if keys would contain '=', which they really shouldn't. 5) reject non-UTF-8 secrets and keys. For keys, that is not an issue, because such keys were never valid. For secrets, it probably didn't work anyway to specify non-UTF-8 secrets, because most (if not all) secrets are transmitted via D-Bus as strings where arbitrary binary is not allowed. 6) ignore empty lines and lines starting with '#'. 7) ensure we don't leak any secrets in memory. 1) to 4) are changes in behavior. 3) and 4) seem less severe, as they only concern unusual setting.property keys, which really shouldn't be used (although, VPN secrets can have almost arbitrary names *sigh*). 1) and 2) is more dangerous, as it changes behavior for secrets that contain backslashes or leading/trailing white space.
* clients: add support for ethtool coalesce settingsAntonio Cardace2020-05-131-38/+107
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1614700
* cli: unref main loop after destroying NMClient instanceBeniamino Galvani2020-05-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Callbacks might reference the main loop when destroying the NMClient instance. Unref the main loop later. # G_DEBUG=fatal-warnings valgrind --num-callers=100 nmcli device wifi connect home ^C Error: nmcli terminated by signal Interrupt (2) Error: Connection activation failed: (0) No reason given. ==11050== Invalid read of size 4 ==11050== at 0x4C90D3D: g_main_loop_quit (in /usr/lib64/libglib-2.0.so.0.6200.6) ==11050== by 0x431435: quit (devices.c:934) ==11050== by 0x43272C: connected_state_cb (devices.c:1919) ==11050== by 0x4BF6741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6200.6) ==11050== by 0x4C0A603: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6) ==11050== by 0x4C133AD: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6200.6) ==11050== by 0x4C139D2: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.6200.6) ==11050== by 0x4BFB1C3: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6) ==11050== by 0x4BFAAEC: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6) ==11050== by 0x4BFD86A: g_object_thaw_notify (in /usr/lib64/libgobject-2.0.so.0.6200.6) ==11050== by 0x48BA040: _nm_client_notify_event_emit (nm-client.c:937) ==11050== by 0x48CA01F: _dbus_handle_changes_commit (nm-client.c:2850) ==11050== by 0x48CC221: _dbus_handle_changes (nm-client.c:2864) ==11050== by 0x48CC833: _init_release_all (nm-client.c:6969) ==11050== by 0x48D2818: dispose (nm-client.c:7826) ==11050== by 0x4BFBC27: g_object_unref (in /usr/lib64/libgobject-2.0.so.0.6200.6) ==11050== by 0x43FF93: nmc_cleanup (nmcli.c:941) ==11050== by 0x4410AD: main (nmcli.c:1005) ==11050== Address 0x54738fc is 12 bytes inside a block of size 16 free'd ==11050== at 0x4839A0C: free (vg_replace_malloc.c:540) ==11050== by 0x4C9649C: g_free (in /usr/lib64/libglib-2.0.so.0.6200.6) ==11050== by 0x4410A3: main (nmcli.c:1004) ==11050== Block was alloc'd at ==11050== at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==11050== by 0x4C96400: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6200.6) ==11050== by 0x4C90A45: g_main_loop_new (in /usr/lib64/libglib-2.0.so.0.6200.6) ==11050== by 0x441020: main (nmcli.c:987) https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/501
* cli: avoid empty if block without a commentThomas Haller2020-05-073-0/+11
| | | | | | | | | lgtm.com flags this as "Empty block without comment". Avoid it. This code is of course ugly. Much work was already done to port such occurrences, and more is needed. I won't add a FIXME comment, because lgtm.com flags those too. :)
* cli: avoid redundant "if" check that is always TRUE in ↵Thomas Haller2020-05-071-1/+1
| | | | nmcli_editor_tab_completion()
* cli: avoid non-thread-safe localtime() function in nmcliThomas Haller2020-05-071-1/+3
| | | | | | | | Static analysis tools flag the use of localtime() because it is not thread safe. Of course, that was no problem here, but avoiding the warning is simple. Also, if we allocate 128 bytes, let strftime use it.
* cli/polkit: add missing variable initialization in retrieve_session_id_cb()Beniamino Galvani2020-05-071-1/+1
| | | | | | | | | | Reported by coverity: >>> CID 210213 Uninitialized pointer read (UNINIT) >>> Using uninitialized value iter when calling _nm_auto_free_variant_iter Fixes: df1d214b2ea7 ('clients: polkit-agent: implement polkit agent without using libpolkit')
* cli/polkit: add missing variable initialization in dbus_method_call_cb()Beniamino Galvani2020-05-071-1/+1
| | | | | | | | | | Reported by coverity: >>> CID 210217: (UNINIT) >>> Using uninitialized value "identities_gvariant" when calling "gs_local_variant_unref". Fixes: df1d214b2ea7 ('clients: polkit-agent: implement polkit agent without using libpolkit')
* cli: use default implementation of getter for NMSettingMatch propertiesThomas Haller2020-05-061-102/+3
| | | | The default implementation should be good enough. Use it.
* settings: add match for driverAdrian Freihofer2020-05-062-0/+46
| | | | | | Add a new "driver" match option to nm-settings. It allows to disable a network connection configuration if a pattern is found or is not found in the device driver name.
* settings: add match for proc cmdlineAdrian Freihofer2020-05-062-0/+46
| | | | | | Add a new "kernel-command-line" match option to nm-settings. It allows to disable a network connection configuration if a pattern is found or is not found in /proc/cmdline.
* nm-setting-bridge: add 'multicast-startup-query-interval' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-startup-query-count' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-query-response-interval' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-query-interval' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-querier-interval' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-membership-interval' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-last-member-interval' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-last-member-count' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-hash-max' bridge optionAntonio Cardace2020-05-042-0/+5
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-online: allow configuring timeout via NM_ONLINE_TIMEOUT environmentThomas Haller2020-04-301-1/+3
| | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1828458 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/484
* 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
|
* 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-281-1/+1
| | | | | | | | | | | | | | | | | | 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.
* libnm/doc: clarify use of "ipv[46].gateway in nm-settings manualThomas Haller2020-04-261-2/+2
|
* 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.
* dhcp: add support for MUD URL (RFC 8520)Eliot Lear2020-04-245-516/+658
| | | | | | | | | | | [thaller@redhat.com: rewritten commit message] https://tools.ietf.org/html/rfc8520 https://blog.apnic.net/2019/05/14/protecting-the-internet-of-things-with-mud/ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/402 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/463
* cli: unset "ipv[46].never-default" when setting "ipv[46].gateway"Thomas Haller2020-04-222-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit c1907a218a6b ('libnm-core: remove gateway when never-default=yes in NMSettingIPConfig'), the gateway gets normalized away when the profile has never-default set. That means, $ nmcli connection modify "$PROFILE" ipv4.never-default yes ipv4.gateway 192.168.77.1 does not set the gateway. Likewise, if your profile has already never-default enabled, $ nmcli connection modify "$PROFILE" ipv4.gateway 192.168.77.1 will have no effect. That is confusing and undesirable. Note that we don't adjust the GObject property setter for "gateway" to clear never-default. I feel, setting one property in libnm should preferably not unset another (there are exceptions to the rule, like for team properties). However, for nmcli it's clear in which order properties are set, so this change is right for the client tool. https://bugzilla.redhat.com/show_bug.cgi?id=1785039 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/475
* wireguard: don't let explicit gateway override WireGuard's peer routeThomas Haller2020-04-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The profile's "ipv4.gateway" and "ipv6.gateway" has only one real purpose: to define the next hop of a static default route. Usually, when specifying a gateway in this way, the default route from other addressing methods (like DHCPv4 or IPv6 autoconf) gets ignored. If you have a WireGuard peer with "AllowedIPs=0.0.0.0/0" and "wireguard.peer-routes" enabled, NetworkManager would automatically add a route to the peer. Previously, if the user also set a gateway, that route was suppressed. That doesn't feel right. Note that configuring a gateway on a WireGuard profile is likely to be wrong to begin with. At least, unless you take otherwise care to avoid routing loops. If you take care, setting a gateway may work, but it would feel clearer to instead just add an explicit /0 manual route instead. Also, note that usually you don't need a gateway anyway. WireGuard is a Layer 3 (IP) tunnel, where the next hop is alway just the other side of the tunnel. The next hop has little effect on the routes that you configure on a WireGuard interface. What however matters is whether a default route is present or not. Also, an explicit gateway probably works badly with "ipv[46].ip4-auto-default-route", because in that case the automatism should add a /0 peer-route route in a separate routing table. The explicit gateway interferes with that too. Nonetheless, without this patch it's not obvious why the /0 peer route gets suppressed when a gateway is set. Don't allow for that, and always add the peer-route. Probably the profile's gateway setting is still wrong and causes the profile not to work. But at least, you see all routes configured, and it's clearer where the (wrong) default route to the gateway comes from.
* wireguard: suppress automatic "wireguard.peer-routes" for default routes if ↵Thomas Haller2020-04-221-1/+1
| | | | | | | "ipv[46].never-default" is enabled Enabling both peer-routes and never-default conflicts with having AllowedIPs set to a default route. Let never-default win.
View Lorry Controller Status