Showcase nm_client_dbus_set_property().
Thereby, also print error messages and return an error if
the command fails.
Also, enable PolicyKit authentication (although, I think there are
some bugs with this still).
Previously, we would call the synchronous nm_client_networking_set_enabled()
method. There were 3 problems:
1) nmcli ignored the return value, that means, if the request failed with
access denied it would just silently pretend that it succeeded.
2) nmcli first called nmc_start_polkit_agent_start_try(), but when
invoking the synchronous method, the main context is busy and a
polkit request cannot possibly be handled.
3) nm_client_networking_set_enabled() is deprecated.
Fix all of these, by calling the D-Bus method directly.
Policykit authentication requests are only handled partly. There
seems to be an unrelated race/bug. Now it works sometimes.
This is more a showcase for using nm_client_dbus_call(), than a
real use.
In this case, nmcli was mostly fine to just invoke the synchronous API
and not care about the problems that it had.
Still, replace it, and show the suggested alternative.
With 1.22, various synchronous functions for invoking D-Bus methods were
deprecated. The reason was that D-Bus is fundamentally asynchronous, and
providing synchronous API in NMClient is inherently wrong. That is
because NMClient essentially is a cache of the D-Bus API, and invoking
g_dbus_connection_call_sync() messes up the order of events from D-Bus.
In particular, when the synchronous function completes, the content of
the cache does not yet reflect the change.
Since they got deprecated, the question is with what to replace them.
Instead of adding a (e.g.) nm_client_networking_set_enabled_async()
for nm_client_networking_set_enabled(), just expect the user to call
D-Bus directly.
D-Bus itself defines a reasonable API, and with GDBusConnection it
is fine (and convenient) to just call D-Bus operations directly.
Often libraries try to abstract D-Bus by providing convenience
wrappers around D-Bus API. I think that often is wrong and unnecessary.
Note that libnm's NMClient does a lot more than just wrapping simple
D-Bus calls. It provides a complete client-side cache of the D-Bus
interface. As such, what libnm's NMClient does is more than simple
wrappers around D-Bus. NMClient is a reasonable thing to do.
However, it is unnecessary to add API like nm_client_networking_set_enabled_async()
that only calls g_dbus_connection_call(). Don't pretend that we would need such
trivial wrappers in libnm.
Instead, recommend to use g_dbus_connection_call(). Or alternatively,
the convenience wrappers nm_client_dbus_call() and
nm_client_dbus_set_property().
Similar to nm_client_dbus_call(), but useful for setting a D-Bus
property on NetworkManager's D-Bus interface.
Note that we currently have various synchronous API for setting D-Bus
properties (like nm_client_networking_set_enabled()). Synchronous
API does not play well with the content of NMClient's cache, and was
thus deprecated. However, until now no async variant exists.
Instead of adding multiple async operations, I think it should be
sufficient to only add one nm_client_dbus_set_property() property.
It's still reasonably convenient to use for setting a property.
Add an API for calling D-Bus methods arbitrary objects of
NetworkManager's API.
Of course, this is basically just a call to g_dbus_connection_call(),
using the current name owner, nm_client_get_dbus_connection() and
nm_client_get_main_context().
All of this could also be achieved without this new API. However,
nm_client_dbus_call() also gracefully handles if the current name
owner is %NULL.
It's a valid concern whether such API is useful, as the users already
have all pieces to do it themself. I think it is.
Move local variables to inner scope.
Also, drop code comment that doesn't give additional information
beyond what is already plainly visible in source code.
When we receive a "InterfaceRemoved" signal, we will end up calling
set_state_down(). That emits a "state" change signal, which causes
NMDeviceWifi to unref the supplicant interface. This may already
give up the last reference, and we cleanup the supplicant state
(by again calling set_state_down()). When we return, set_state_down()
will crash because it operates on an already destroyed instance.
Avoid that by keeping a reference to the interface during set_state_down().
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
https://bugzilla.redhat.com/show_bug.cgi?id=1815058
This solves a bug exposed by the following cmds:
$ nmcli c add type bond ifname bond0 con-name bond0
$ nmcli c modify bond0 +bond.options miimon=100
$ nmcli -f bond.options c show bond0
bond.options: mode=balance-rr
Here we just added the option 'miimon=100', but it doesn't get saved in
because nm_settings_connection_set_connection() which is responsible for
actually updating the connection compares the new connection with old
one and if and only if the 2 are different the update is carried out.
The bug is triggered because when comparing, if default values are taken into
account, then having 'miimon=100' or not having it it's essentially the
same for compare(). While this doesn't cause a bond to have a wrong
setting when activated it's wrong from a user experience point of view
and thus must be fixed.
When this patch is applied, the above
commands will give the following results:
$ nmcli c add type bond ifname bond0 con-name bond0
$ nmcli c modify bond0 +bond.options miimon=100
$ nmcli -f bond.options c show bond0
bond.options: mode=balance-rr,miimon=100
Fix unit tests and also add a new case covering this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1806549
Since ifcfg-rh doesn't write out to file the 'connection.timestamp' property
let's add it before comparing an updated connection with the plugin's reread
one otherwise the comparison operation would always fail.
The fix is not necessary for the keyfile plugin, because the reader/writer
correctly reads/writes the connection timestamp.
Drop the special casing of not scanning. Now do_device_wifi_list()
always handles the scan list in a callback.
Also fix the error code for scanning for a certain "bssid", which
previously was not set if scanning was not performed:
$ nmcli device wifi list --rescan no bssid bogus
Success
This fixes the pipeline as 'gem' will be installed by default in the
container image.
Also fix wording and run gitlab-triage in debug mode to get more output.
For many purposes, the supplicant features are not very interesting (as
they are also mostly static for a certain release/distribution). Combine
the multiple logging lines into one.
Also, sort the NMSupplCapType enum values consistently with the order
in which we log them.
Also, rename the logging output for features to match the enum name.
E.g. "FAST" instead of "EAP-FAST".
Now:
> supplicant: supported features: AP+ PMF+ FILS- P2P+ FT+ SHA384+ MESH+ FAST+ WFD+
When a device gets a prefix delegation, we call
nm_device_use_ip6_subnet() for all other devices that have IPv6
sharing enabled, which changes the current IPv6 configuration and
notifies NMPolicy. When updating the DNS configuration in NMPolicy, we
should notify all devices except the one that triggered the change.
https://bugzilla.redhat.com/show_bug.cgi?id=1488030
Configuration stages like act_stage2_config() can postpone progressing
to the next stage. Currently, when the condition that we wait for gets
satisfied, the code schedules the next stage from there.
I think that is wrong, because when we postpone from act_stage2_config(),
follow up steps of stage2 get skipped. Thus, when we are ready to progress,
the class should enter stage 2 again.
This requires that stage2 becomes reentrant and that the code reenters the
same stage.
We usually want to schedule stage2 when we just completed with the previous
stage (or, if we are currently in stage2, and want to re-enter it).
In those cases, the conditions are often right to just proceed right away.
No need to schedule the stage on an idle handler. Allow to invoke stage2
right away.
There was only API to schedule the stage on an idle handler.
Sometimes, we are just in the right situation to schedule the stage
right away. It should be possibly to avoid going through the extra hop.
For now, none of the caller makes use of this. So, there isn't any
actual change in behavior. But by adding this possibility, we may do
use in the future.
cols_len might be larger than header_row->len. That is when
the cols has entries that are not leaf entries (which currently
I think is never the case).
Fix it to use the right variable for the length of the row.
