summaryrefslogtreecommitdiff
path: root/src/nmcli
Commit message (Collapse)AuthorAgeFilesLines
* mptcp: rework "connection.mptcp-flags" for enabling MPTCPThomas Haller2022-08-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) The "enabled-on-global-iface" flag was odd. Instead, have only and "enabled" flag and skip (by default) endpoints on interface that have no default route. With the new flag "also-without-default-route", this can be overruled. So previous "enabled-on-global-default" now is the same as "enabled", and "enabled" from before behaves now like "enabled,also-without-default-route". 2) What was also odd, as that the fallback default value for the flags depends on "/proc/sys/net/mptcp/enabled". There was not one fixed fallback default, instead the used fallback value was either "enabled-on-global-iface,subflow" or "disabled". Usually that is not a problem (e.g. the default value for "ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case it is a problem, because the mptcp-flags (for better or worse) encode different things at the same time. Consider that the mptcp-flags can also have their default configured in "NetworkManager.conf", a user who wants to switch the address flags could previously do: [connection.mptcp] connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer honored. That means, MPTCP handling was always on, even if the sysctl was disabled. Now, "enabled" means that it's only enabled if the sysctl is enabled too. Now the user could write to "NetworkManager.conf" [connection.mptcp] connection.mptcp-flags=0x32 # enabled,signal,subflow and MPTCP handling would still be disabled unless the sysctl is enabled. There is now also a new flag "also-without-sysctl", so if you want to really enable MPTCP handling regardless of the sysctl, you can. The point of that might be, that we still can configure endpoints, even if kernel won't do anything with them. Then you could just flip the sysctl, and it would start working (as NetworkManager configured the endpoints already). Fixes: eb083eece5a2 ('all: add NMMptcpFlags and connection.mptcp-flags property') (cherry picked from commit c00873e08f4d0bc4a3f0b8a93beb793fcab78afa)
* libnm: reword documentation for "ipv4.gateway" and "ipv6.gateway"Thomas Haller2022-08-231-2/+2
| | | | (cherry picked from commit 0e26203e02969ce6e4475ea3bb2acfcdafed1a37)
* Revert "wifi: support ↵Thomas Haller2022-08-111-1/+1
| | | | | | | | | | | | | | | "802-1x.phase1-auth-flags=tls-allow-unsafe-renegotiation" flag" There is still no agreement, about how to name this option, or whether it should exist at all. Revert the addition of the flag. As the new release is coming up, drop the new API. https://bugzilla.redhat.com/show_bug.cgi?id=2072070#c64 https://bugzilla.redhat.com/show_bug.cgi?id=2077973#c24 http://lists.infradead.org/pipermail/hostap/2022-July/040665.html This reverts commit a5a4aea2e627214a3da3c6fdb2651d65a7182ea8.
* all: drop various NMMptcpFlagsThomas Haller2022-08-091-1/+1
| | | | | The default behavior might be sufficient. Drop those flags for now, and figure out a good solution when we have an actual use-case.
* all: add NMMptcpFlags and connection.mptcp-flags propertyThomas Haller2022-08-091-0/+2
|
* nmcli-completion: fix support for embedded quote charactersavery2022-08-041-1/+1
| | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/455 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1325 Fixes: 9d2290135ce5 ('cli: make nmcli do its own command completion')
* nmcli: move an assignment down to where the value neededLubomir Rintel2022-07-291-2/+2
| | | | | | It's happier there. No change in behavior. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1317
* nmcli: do not assume active connection has a settings connectionLubomir Rintel2022-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | The reproducer for another problem tripped an assertion failure: $ nmcli con del act-conn Connection 'act-conn' (...) successfully deleted. $ nmcli con down another-conn (process:94552): nm-CRITICAL **: 17:07:21.170: ((src/libnm-client-impl/nm-remote-connection.c:593)): assertion '<dropped>' failed Connection 'another-conn' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4) $ What happens is that the second invocation, when resolving the connection name into a NMRemoteConnection object, assumes an active connection has a settings connection. This assumption is likely to be wrong immediately after deleting a connection was active, before giving the active connection enough time to fully deactivate. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1317
* libnm-client: Add public nm_conn_wireguard_import() funcChristian Glombek2022-07-211-1/+1
| | | | | | | | | | | | This commit moves the `nm_vpn_wireguard_import()` function implementation from `libnmc-base` to `libnm-client-impl`, renaming it to `nm_conn_wireguard_import()`. A new `nm_conn_utils` header file is added in `libnm-client-public`. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1031 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1299
* all: reformat with clang-format (clang-tools-extra-14.0.0-1.fc36) and update ↵Thomas Haller2022-07-062-7/+7
| | | | gitlab-ci to f36
* libnm/docs: expand documentation for wireguard.ip4-auto-default-routeThomas Haller2022-06-301-1/+1
|
* all: make "ipv6.addr-gen-mode" configurable by global defaultThomas Haller2022-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It can be useful to choose a different "ipv6.addr-gen-mode". And it can be useful to override the default for a set of profiles. For example, in cloud or in a data center, stable-privacy might not be the best choice. Add a mechanism to override the default via global defaults in NetworkManager.conf: # /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf [connection-90-ipv6-addr-gen-mode-override] match-device=type:ethernet ipv6.addr-gen-mode=0 "ipv6.addr-gen-mode" is a special property, because its default depends on the component that configures the profile. - when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode key means to default to "eui64". - when configured via D-Bus, a missing addr-gen-mode property means to default to "stable-privacy". - libnm's ip6-config::addr-gen-mode property defaults to "stable-privacy". - when some tool creates a profile, they either can explicitly set the mode, or they get the default of the underlying mechanisms above. - nm-initrd-generator explicitly sets "eui64" for profiles it creates. - nmcli doesn' explicitly set it, but inherits the default form libnm's ip6-config::addr-gen-mode. - when NM creates a auto-default-connection for ethernet ("Wired connection 1"), it inherits the default from libnm's ip6-config::addr-gen-mode. Global connection defaults only take effect when the per-profile value is set to a special default/unset value. To account for the different cases above, we add two such special values: "default" and "default-or-eui64". That's something we didn't do before, but it seams useful and easy to understand. Also, this neatly expresses the current behaviors we already have. E.g. if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64" is a pretty clear thing. Note that usually we cannot change default values, in particular not for libnm's properties. That is because we don't serialize the default values to D-Bus/keyfile, so if we change the default, we change behavior. Here we change from "stable-privacy" to "default" and from "eui64" to "default-or-eui64". That means, the user only experiences a change in behavior, if they have a ".conf" file that overrides the default. https://bugzilla.redhat.com/show_bug.cgi?id=1743161 https://bugzilla.redhat.com/show_bug.cgi?id=2082682 See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
* nmcli/connections: fix setting ifname with "--ask c add"lr/ask-modeLubomir Rintel2022-06-241-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We almost always do the wrong thing in interactive add: The software devices generally require an interactive name, but we don't insist of asking for them; treating them as optional: $ nmcli -a c add type dummy There is 1 optional setting for General settings. Do you want to provide it? (yes/no) [yes] For some interface types (bridges, bonds, ...) we make up a name, presumably for historical reasons. But we don't give the user an option to modify them: $ nmcli -a c add type bridge <not asking for interface name at all> There are 9 optional settings for Bridge device. Do you want to provide them? (yes/no) [yes] This fixes the above use cases -- still set the default, but be sure to ask: $ nmcli -a c add type dummy Interface name: $ nmcli -a c add type bridge Interface name [nm-bridge1]: Beautiful.
* nmcli/connections: make sure the connection has a base settingLubomir Rintel2022-06-241-0/+6
| | | | | | | | | | | | Do the same bookkeeping as would happen upon setting the "type" option when the connection has a connection.type set upon its addition. Otherwise the --ask mode is sad: $ nmcli --ask c add connection.type team ** nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting) Bail out! nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting) Aborted (core dumped)
* nmcli/connections: factor out code run after new connection's type is setLubomir Rintel2022-06-241-21/+33
| | | | | | | | | | | | | | | | | | | | | | | | After the connection's type is set, some bookkeeping is necessary for the interactive (--ask) mode: appropriate setting need to be added and options enabled. Currently it happens in an option setter; which runs when the "type" options is present on the command line, or the value is set in a response to interactive mode: $ nmcli --ask c add type team $ nmcli --ask c add Connection type: team But not when the property is set directly: $ nmcli --ask c add connection.type team ** nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting) Bail out! nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting) Aborted (core dumped) This doesn't fix the issue -- a followup commit (hopefully) will.
* nmcli/connections: use the current value in default in ask_option()Lubomir Rintel2022-06-241-2/+15
| | | | | | | | | | | For new connections, this ensures the value in square brackets on interactive add are always correct. Apart from that, this allows us to initialize some non-default values before asking (such as making up an interface name for some software devices), and inform the user about what we picked: Interface name [nm-bridge]:
* nmcli/connections: don't ask to ask with --askLubomir Rintel2022-06-241-9/+7
| | | | | | | | | | | | This is slightly annoying: $ nmcli -a c add type ethernet There is 1 optional setting for General settings. No point in asking if there's just one option. Just ask right away: $ nmcli -a c add type ethernet Interface name:
* nmcli/connections: make sure the connection has a typeLubomir Rintel2022-06-241-3/+10
| | | | | We use it before we validate the connection, thus need to check if it's actually there.
* nmcli/connections: make enable_options() always enable an optionLubomir Rintel2022-06-241-10/+6
|
* nmcli/connections: make opts argument to enable_options() optionalLubomir Rintel2022-06-241-6/+15
| | | | | This makes things slightly less annoying when dealing with options that map nicely to properties (unlike bridge options).
* nmcli/connections: allow empty lists with "--ask c add"Lubomir Rintel2022-06-241-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The interactive add is not too enthusiastic about not providing a value in a list. That is before on getting an empty line in ask_option() we take a shortcut instead of dispatching to set_option(). That way we skip setting the PROPERTY_INF_FLAG_DISABLED flag, causing the option to be included in questionnaire_one_optional()'s info list. There's no reason to avoid calling set_option() if we don't get a value; set_option() handles NULL value just fine. $ nmcli -a c add Connection type: dummy There is 1 optional setting for General settings. Do you want to provide it? (yes/no) [yes] Interface name [*]: lala There are 2 optional settings for IPv4 protocol. Do you want to provide them? (yes/no) [yes] You can specify this option more than once. Press <Enter> when you're done. IPv4 address (IP[/plen]) [none]: You can specify this option more than once. Press <Enter> when you're done. IPv4 address (IP[/plen]) [none]: You can specify this option more than once. Press <Enter> when you're done. IPv4 address (IP[/plen]) [none]: ...
* nmcli/connections: do not remove a bond option unless reset is allowedLubomir Rintel2022-06-241-17/+15
| | | | | If we're setting an option with no value given and no reset allowed, let's just set the default value.
* nmcli/connections: pass allow_reset to check_and_set() callbackLubomir Rintel2022-06-241-1/+16
| | | | | Like the regular set_option() handler, the special ones also need to know whether to reset an option or keep the value.
* nmcli/devices: fix a crashLubomir Rintel2022-06-231-2/+2
| | | | | | | | | This is not good: $ nmcli device delete nm-bond Segmentation fault (core dumped) Fixes: 5f9d2927ed02 ("nmcli/devices: use GPtrArray from get_device_list() directly")
* merge: branch 'lr/nmcli-checkpoint'Lubomir Rintel2022-06-232-90/+320
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1207
| * nmcli/devices: add "checkpoint" commandlr/nmcli-checkpointLubomir Rintel2022-06-151-1/+222
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an interface to the Checkpoint/Restore functionality that's available for quite some time. It runs a command with a checkpoint taken and rolls back unless success is confirmed before the checkpoint times out: $ nmcli dev checkpoint eth0 -- nmcli dev dis eth0 Device 'eth0' successfully disconnected. Type "Yes" to commit the changes: No Checkpoint was removed. The details about how it's used are documented in nmcli(1) and nmcli-examples(7).
| * nmcli: be less insistant on exiting when readline() gets no inputLubomir Rintel2022-06-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | When the input ends, we indeed eventually want to shut down. Nevertheless, it might be that we terminated the input *because* we're already shutting down and want do do our cleanup. Let's not take the shortcut to nmc_exit() in case the main loop is no longer running. This doesn't affect existing uses of nmc_readline(), but will be useful in a future patch.
| * nmcli/devices: use GPtrArray from get_device_list() directlyLubomir Rintel2022-06-151-32/+23
| | | | | | | | | | | | | | | | | | This makes get_device_list() return an array of NMDevices with a reference taken and a destroy notifier that unhooks disconnect_state_cb, so that it could replace the GSList of the same utility used by disconnect/delete commands. Suggested-by: Thomas Haller <thaller@redhat.com>
| * nmcli/devices: return GPtrArray instead of GSList from get_device_list()Lubomir Rintel2022-06-151-43/+35
| | | | | | | | | | | | | | | | | | | | | | A pointer array is slightly more efficient here, since we don't really need the ability to insert elements in the middle. In fact, we'd prefer if we could just add to the end, so that we'd spare some callers from a need to do a g_slist_reverse(). Even though that alone being a good reason to use a GPtrArray instead of GSList, I'm doing this for so that I could actually use the returned value as-is in a call to nm_client_checkpoint_create() in a future patch.
| * nmcli/devices: make get_device_list() terminate on "--"Lubomir Rintel2022-06-151-0/+22
| | | | | | | | | | | | | | | | Don't consider "--" a device name. Instead, treat it as a signal to stop reading the device list. If a caller expects nothing beyond the device names, it now has to check.
| * nmcli/devices: make get_device_list() shift argc/argvLubomir Rintel2022-06-151-25/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this patch, get_device_list() would give the caller no clue about how many options did it consume. That is okay -- it would always process all argument until the end, so the no callers would really care. In a further patch, I'd like to allow termination of the device name list (with a "--" arguments), so it will be possible to specify further arguments. Let's change the protype of this routine to use pointers to argc/argv, that it will be possible to adjust them.
* | libnm/docs: add comment about background scanning to wifi.bssid propertyThomas Haller2022-06-211-1/+1
| |
* | nmcli: distinguish OWE-TM from OWE BSSDavid Bauer2022-06-171-2/+3
| | | | | | | | | | | | | | Distinguish a OWE-TM enabled BSS (which itself is unencrypted) from the OWE BSS actually employing encryption. Signed-off-by: David Bauer <mail@david-bauer.net>
* | libnm/docs: elaborate how ipv4.dns-search/ipv6.dns-search worksThomas Haller2022-06-171-2/+2
| |
* | cli: reformat file to look betterThomas Haller2022-06-161-49/+105
| | | | | | | | | | | | Comments on the same line as field names are not rendered well by clang-format. Even if manually edited, it seems not a preferable way to comment on a field. Move the comment in the line before.
* | libnm: support wait-activation-delay propertyFernando Fernandez Mancera2022-06-161-0/+2
|/ | | | | | | | | | | | | | | | | | | | The property wait-activation-delay will delay the activation of an interface the specified amount of milliseconds. Please notice that it could be delayed some milliseconds more due to other events in NetworkManager. This could be used in multiple scenarios where the user needs to define an arbitrary delay e.g LACP bond configure where the LACP negotiation takes a few seconds and traffic is not allowed, so they would like to use nm-online and a setting configured with this new property to wait some seconds. Therefore, when nm-online is finished, LACP bond should be ready to receive traffic. The delay will happen right before the device is ready to be activated. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1248 https://bugzilla.redhat.com/show_bug.cgi?id=2008337
* nmcli: add nmcli gen reload usageRyosuke YASUOKA2022-06-151-2/+3
| | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1257 Signed-off-by: Ryosuke Yasuoka <yasuoka0830@gmail.com>
* device: introduce ipv6.mtu propertyAlex Henrie2022-05-271-0/+2
| | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1003 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1231
* settings: add ipv4.link-local flagAdrian Freihofer2022-05-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduction of a new setting ipv4.link-local, which enables link-local IP addresses concurrently with other IP address assignment implementations such as dhcp or manually. No way is implemented to obtain a link-local address as a fallback when dhcp does not respond (as dhcpd does, for example). This could be be added later. To maintain backward compatibility with ipv4.method ipv4.link-local has lower priority than ipv4.method. This results in: * method=link-local overrules link-local=disabled * method=disabled overrules link-local=enabled Furthermore, link-local=auto means that method defines whether link-local is enabled or disabled: * method=link-local --> link-local=enabled * else --> link-local=disabled The upside is, that this implementation requires no normalization. Normalization is confusing to implement, because to get it really right, we probably should support normalizing link-local based on method, but also vice versa. And since the method affects how other properties validate/normalize, it's hard to normalize that one, so that the result makes sense. Normalization is also often not great to the user, because it basically means to modify the profile based on other settings. The downside is that the auto flag becomes API and exists because we need backward compatibility with ipv4.method. We would never add this flag, if we would redesign "ipv4.method" (by replacing by per-method-specific settings). Defining a default setting for ipv4.link-local in the global configuration is also supported. The default setting for the new property can be "default", since old users upgrading to a new version that supports ipv4.link-local will not have configured the global default in NetworkManager.conf. Therefore, they will always use the expected "auto" default unless they change their configuration. Co-Authored-By: Thomas Haller <thaller@redhat.com>
* wifi: support "802-1x.phase1-auth-flags=tls-allow-unsafe-renegotiation" flagThomas Haller2022-05-161-1/+1
| | | | | | | | | | | | | For details, read the linked sources. This requires a new supplicant option, but it seems that supplicant will silently ignore unrecognized options. https://bugzilla.redhat.com/show_bug.cgi?id=2072070#c48 https://lists.infradead.org/pipermail/hostap/2022-May/040522.html https://w1.fi/cgit/hostap/commit/?id=566ce69a8d0e64093309cbde80235aa522fbf84e https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1218
* build/meson: use "rename" directive for installing nmcli bash completionThomas Haller2022-05-131-3/+1
| | | | | | | Otherwise, `ninja -C build uninstall` tries to delete "nmcli-completion", when the file got renamed to "nmcli". We depend on meson 0.47.2 already.
* nmcli/devices: fix sorting of APsLubomir Rintel2022-05-121-1/+1
| | | | | | | | Sort WEP access points as intended -- down, not up. Fixes: 550e3bbdd8f5 ('cli: device: color WEP APs differently in "wifi list"') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
* nmcli/devices: check connection created with "wifi connect"Lubomir Rintel2022-05-121-0/+6
| | | | | | | | | | | | | | We want to warn the user if they're connecting to an insecure network: $ nmcli d wifi IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY BA:00:6A:3C:C2:09 Secured Network Infra 2 54 Mbit/s 100 ▂▄▆█ WPA3 FA:7C:46:CC:9F:BE Ye Olde Wlan Infra 1 54 Mbit/s 100 ▂▄▆█ WEP $ nmcli d wifi connect 'Ye Olde Wlan' Warning: WEP encryption is known to be insecure. ... https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
* nmcli/connections: export nmc_connection_check_deprecated()Lubomir Rintel2022-05-122-5/+8
| | | | | | | It's going to be useful with "nmcli dev wifi connect" that also creates a connection that should be checked. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
* core: change the priority order in static "ipv6.addresses"Thomas Haller2022-04-271-1/+1
| | | | | | | | | | | | | The order of addresses matters. For "ipv4.addresses", the list contains the primary address first. For "ipv6.addresses", the order was reverted. This was also documented behavior. The previous patch just changed behavior with respect to relative order of static IPv6 addresses and autoconf6/DHCPv6. As we seem in the mood for changing behavior, here is another one. Now the addresses are interpreted in an order consistent with IPv4 and how one might expect: preferred addresses first.
* nmcli: add --offline option for "add" and "modify"Lubomir Rintel2022-04-194-72/+366
| | | | | | | | | | | | | | | | | | | | | This adds a global "--offline" option and allows its use with "add" and "modify" commands. The "add" looks like this: $ nmcli --offline conn add type ethernet ens3 ipv4.dns 192.168.1.1 \ >output.nmconnection The "modify" is essentially implementing what's been suggested by Beniamino in bugzilla ticked (referred to below): $ nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 \ <input.nmconnection >output.nmconnection Other commands don't support the argument at the moment: $ nmcli --offline c up ens3 Error: 'up' command doesn't support --offline mode. https://bugzilla.redhat.com/show_bug.cgi?id=1361145
* nmcli/trivial: consistently order the options in process_command_line()Lubomir Rintel2022-04-191-2/+2
| | | | | | Make the order of nmc_complete_strings() arguments consistent with the multi-way conditional below. Doesn't have any effect, just ensures the ommisions and mistakes are hopefully easier to spot.
* nmcli.h: tidy up boolean struct membersLubomir Rintel2022-04-191-25/+30
| | | | | | | | | Use bitfields to save a few bytes. This involves swapping gboolean for bool and some reordering in order to get them grouped together. The patch looks horrible, because clang-format decides to put itself and seem to go out of its way to make this whole file look idiotic. What can you do.
* cli: indicate missing radio hardware in "nmcli radio"Beniamino Galvani2022-03-291-0/+10
| | | | | | | | | | | | | | When no radio hardware is present in the system, "nmcli radio" currently displays: WIFI-HW WIFI WWAN-HW WWAN enabled enabled enabled enabled which is misleading. Use the new RadioFlags property to display "missing" in the *-HW columns when there is no hardware for the given radio technology. https://bugzilla.redhat.com/show_bug.cgi?id=1996918
* cli: remove one more g_assert()Lubomir Rintel2022-03-281-1/+1
| | | | | | | | | | I pushed accidentally pushed commit 9702310f25af ('clients: bulk removal of g_assert*() statements') earlier than I intended, without addressing one more case introduced by preceding merge. Fix it now. Fixes: 9702310f25af ('clients: bulk removal of g_assert*() statements') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1166
View Lorry Controller Status