It's not used anymore. Which is a good thing, because if it was used
we'd have to get rid of the uses.
It did accept a whitespace separated string for an argument, which is
never useful for us; it indicated error either on g_spawn_sync()
failure or an error status code of the program spawned, but only set the
error in the former case which had let to errors.
The would would be a bit nicer place without it.
(But not much)
nm_spawn_process() only sets error if the g_spawn_sync() itself fails,
not when the program ran returns a non-zero code.
<debug> [148 059915.1567] dns-mgr: update-dns: updating resolv.conf
<info> [148 059915.1568] dns-mgr: Removing DNS information from /usr/bin/resolvconf
No resolv.conf for interface NetworkManager
Thread 1 "NetworkManager" received signal SIGSEGV, Segmentation fault.
0x0000555555 7c325 in nm_dns_manager_end_updates
1532 _LOGW ("could not commit DNS changes: %s", error->message);
(gdb) bt full
#0 0x0000555555 7c325 in nm_dns_manager_end_updates
error = 0x0
When using nm-online -t N, the countdown shows "0s" during the last second.
The countdown value should be rounded up so that "0s" is only shown when the
timeout is actually elapsed.
https://bugzilla.gnome.org/show_bug.cgi?id=778093
The function is used, among others, in the get_property() of many
objects to return a boxed strv from a list. The default value for a
boxed strv property is NULL, but _nm_utils_slist_to_strv() returns a
pointer to an array with zero elements when the list is empty.
Change the function to return NULL if the input list is empty.
Moving nm-online to async init introduced various issues:
- with a timeout of zero, nm-online would terminate with failure
before initializing the NMClient instance.
- add a timeout for safeguarding the async creation of NMClient
- fix adding trailing newline for the progress bar.
While at it, refactor:
- use defines for the exit codes
- don't use exit(), but instead always properly quit the mainloop
and cleanup all resources.
- in non-quiet mode, print the result [online] or [offline] at
the end.
Fixes: c5f17a97eahttps://bugzilla.gnome.org/show_bug.cgi?id=777914
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
MAC_ADDRESS_RANDOMIZATION setting as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
See also commit 46d53e1101 which does
something similar for keyfile.
This bug also prevents a user from clearing the cloned-mac-address:
$ nmcli connection show "$CONN"
...
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization: never
...
$ nmcli connection modify "$CONN: wifi.cloned-mac-address ''
# ^ takes no effect
As workaround, you also need to clear mac-address-randomization:
$ nmcli connection modify "$CONN: wifi.cloned-mac-address '' \
wifi.mac-address-randomization default
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00060.html
c5f17a97ea changed nm-online to determine
the status asynchronously, however this introduced a regression with
"nm-online -x -q" when there is connectivity.
if ( state == NM_STATE_CONNECTED_LOCAL
|| state == NM_STATE_CONNECTED_SITE
|| state == NM_STATE_CONNECTED_GLOBAL) {
data->retval = 0;
g_main_loop_quit (data->loop);
}
}
if (data->exit_no_nm && (state != NM_STATE_CONNECTING)) {
data->retval = 1;
g_main_loop_quit (data->loop);
}
After setting data->retval = 0 in the "state is connected" branch, the
function falls through to the "exit_no_nm and !connecting" branch,
overwriting data->retval. This causes "nm-online -x -q" to incorrectly
report an offline state.
Adding an explicit "return;" after any state where data->retval is set
ensures that the value isn't overwritten before main() uses it.
Fixes: c5f17a97eahttps://mail.gnome.org/archives/networkmanager-list/2017-January/msg00058.html
If the connection spontaneously disappears (perhaps along with the whole
daemon on crash) while we're deleting it, then the removal callback
would free up the context structure the delete operation is using.
Let's cancel the in-flight delete operations so that they won't touch
the structure after it's gone.
After 1.6.0 is released, merge it back into master so that
1.6.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.6.0 and 1.6-rc*.
Also bump the micro version to 1.7.1-dev to indicate that this is
after 1.6.0 is out.
The public property NM_DEVICE_ACTIVATION_REQUEST exposes the exported
D-Bus path. So, it's not sufficient to emit property changed signals
when changing the priv->act_request pointer, we must also react on
exporting/unexporting.
It's not clear whether this fixes an actual bug. Maybe, we never
export/unexport priv->act_request while the device tracks it.
But the code is pretty hard to follow and it's hard to verify
whether this is the case.
By hooking up to "notify::path", we can easily verify that such
a situtation cannot arise.
(cherry picked from commit 9ae5e6a54d)
If a slave device activates, we should keep the master up even though it
was taken over before.
This fixes an issue, where a single slave to a master would be
reactivated after a daemon restart. The daemon restart would cause the
master to be treated externally created (would go unmanaged when all the
slaves are gone) while the reactivation would leave the master without
slaves for a while.
(cherry picked from commit b605fb2712)
Changes:
- match_device_s390_subchannels_parse() should accept un-initialized
arguments a,b,c, as they are striclty output arguments (without
transfering ownership).
- the output arguments should be set if (and only if) the function
succeeds. That is, move assigning the output arguments to the end.
- increase the BUFSIZE. It's unclear why choosing 10. Probably that
was already sufficient as a subchannel looks like
"0.0.f5f0,0.0.f5f1,0.0.f5f2". Still, increase it to be ample.
If we want to restrict the parsing based on the lenght of the input,
that should be done explicitly (but that seems not desirable).
- use _nm_utils_ascii_str_to_int64() which checks that the range
of the values fits in guint32.
It seems wrong that match_device_s390_subchannels_eval() only compares
the first of up to three subchannels. But leave it as is for now.
(cherry picked from commit 419151a19e)
Changes:
- match_device_s390_subchannels_parse() should accept un-initialized
arguments a,b,c, as they are striclty output arguments (without
transfering ownership).
- the output arguments should be set if (and only if) the function
succeeds. That is, move assigning the output arguments to the end.
- increase the BUFSIZE. It's unclear why choosing 10. Probably that
was already sufficient as a subchannel looks like
"0.0.f5f0,0.0.f5f1,0.0.f5f2". Still, increase it to be ample.
If we want to restrict the parsing based on the lenght of the input,
that should be done explicitly (but that seems not desirable).
- use _nm_utils_ascii_str_to_int64() which checks that the range
of the values fits in guint32.
It seems wrong that match_device_s390_subchannels_eval() only compares
the first of up to three subchannels. But leave it as is for now.
If a slave device activates, we should keep the master up even though it
was taken over before.
This fixes an issue, where a single slave to a master would be
reactivated after a daemon restart. The daemon restart would cause the
master to be treated externally created (would go unmanaged when all the
slaves are gone) while the reactivation would leave the master without
slaves for a while.
The public property NM_DEVICE_ACTIVATION_REQUEST exposes the exported
D-Bus path. So, it's not sufficient to emit property changed signals
when changing the priv->act_request pointer, we must also react on
exporting/unexporting.
It's not clear whether this fixes an actual bug. Maybe, we never
export/unexport priv->act_request while the device tracks it.
But the code is pretty hard to follow and it's hard to verify
whether this is the case.
By hooking up to "notify::path", we can easily verify that such
a situtation cannot arise.
For better or worse, nm_exported_object_unexport() asserts that the
object is currently exported.
It's not clear that an active connection at this place is always
exported.
Fixes: f0e3dfdace
(cherry picked from commit c8a649b3de)
The active connection has an immutable connection property, but is
cleaned asynchronously by the manager after its settings connection is
done. Fine, let's remove it from the bus first though, so that we don't
hang there with a dangling object path.
(cherry picked from commit f0e3dfdace)
For better or worse, nm_exported_object_unexport() asserts that the
object is currently exported.
It's not clear that an active connection at this place is always
exported.
Fixes: f0e3dfdace
The active connection has an immutable connection property, but is
cleaned asynchronously by the manager after its settings connection is
done. Fine, let's remove it from the bus first though, so that we don't
hang there with a dangling object path.
