Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
If BOOTPROTO is set to "none", user states that no ipv4 setting should
be set. So respect that.
Introduce helper is_any_ip4_address_defined() along the way to make the
code more readable.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
When reading the property name in edit mode, any white space should be
striped from the entered value. Especially, because tab completion will
add a trailing whitespace.
Example:
$ nmcli connection edit
Enter connection type: ethernet
nmcli> goto connection
nmcli connection> describe
Property name? u<TAB>
The <TAB> will complete 'u' to 'uuid '.
This whitespace should be allowed and striped.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The symbol is part of the public API (included in the GIR file),
and gjs complains loudly if a defined symbol is not found.
https://bugzilla.gnome.org/show_bug.cgi?id=706259
Acked-by: Pavel Šimerda <psimerda@redhat.com>
Rewrite nm-online to use libnm-glib, and change it so that it waits
until NM has finished all of its startup-time connection activation
attempts, rather than only waiting until at least one has succeeded.
In particular, this means that on multi-homed servers, the
NetworkManager-wait-online systemd service (and by extension,
network.service) will now block until *all* of the server's IP
addresses are up, which is needed for some old daemons that assume
that no network interfaces will be added after they start.
Add a property on NMManager indicating that it is currently starting
up and activating startup-time/boot-time network connections.
"startup" is initially TRUE, and becomes FALSE once all NMDevices
report that they have no pending activity (eg, trying to activate,
waiting for a wifi scan to complete, etc). This is tracked via a new
NMDevice:has-pending-activity property, which is maintained partially
by the device itself, and partially by other parts of the code.
nm-manager.c:remove_one_device() took a GSList as an argument and
returned that GSList with the device removed; but every caller passed
in priv->devices and assigned the result to priv->devices, so just
make it always do that.
Also, rename it to remove_device() to match add_device().
Also, when removing a device, NMManager was only disconnecting one of
the several signal handlers it connected in add_device(). This
generally wasn't a problem since the device would normally be
destroyed immediately after this, but it's good to be correct.
In nm_keyfile_plugin_connection_from_file(), disable the "bad owner"
check.
As root you can read all files anyway, or if necessary even chown them,
and for
other users the standard file permissions will do a fine job.
This fixes running "make check" as root.
https://bugzilla.gnome.org/show_bug.cgi?id=701112
Also sub commands can be abbreviated. Add some more aliases to the bash
completion.
Also fix the option 'nmcli radio mobile' which is called 'wwan'.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nmcli accepts abbreviated versions of object names, e.g. 'con'
instead of 'connection'. Adjust bash completion to also support
this.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When a connection is removed from NMSettings, it gets deactivated. That was
happening once in response to the now-removed connection's visibility changing
to invisible to everyone, and a second time in response to the actual removal
signal. Unfortunately the second time the NMActiveConnection is already
cleaned up and in the DEACTIVATED state, and has no priv->device, which
causes great hilarity when nm_device_set_state() is called with NULL.
_deactivate_if_active() should only try to deactivate NMActiveConnections
that actually are active.
Plugins that could save connections to disk previously depended on inotify
events from the kernel to know when to signal connection removal; that is
in response to a 'delete' request they would unlink the backing filesystem
resources, get the inotify signal, and cause NM_SETTINGS_CONNECTION_REMOVED
to be emitted.
Unsaved connections don't have any backing resources, so they would never
get the signal emitted, and NMSettings would never forget about them.
Also, when monitor-connection-files=false in the configuration, obviously
the inotify signals will never come in because they aren't set up.
Given that we can no longer rely on inotify, it's best to just explicitly
send out the NM_SETTINGS_CONNECTION_REMOVED signal whenever a connection
is deleted via the D-Bus interface or internally.
We do not need to increase periodical scanning frequency when AP signal
strength is good enough. Signal level of -45dBm is considered as good,
change the threshold to -65dBm.
platform/nm-linux-platform.c: In function 'delete_object':
platform/nm-linux-platform.c:102:13: error: 'cached_object' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (object && *object) {
^
platform/nm-linux-platform.c:1019:35: note: 'cached_object' was declared here
Except that it won't be, but I guess the gsystem auto* stuff is
confusing the compiler.
