NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive
portal" and "limited network connectivity" (ie, connected to a router
that has lost its upstream connection). Add a new NMManager
:connectivity property to provide this information.
Also add a CheckConnectivity method, which can be used to force NM to
re-check the connectivity state, which could be called by a client
after it completed a portal login, or fixed a network problem.
The connectivity-checking code would generally result in
NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE
in the case where the connectivity check failed. The brief incorrect
CONNECTED_GLOBAL is bad, because clients might see it and do the wrong
thing.
Instead, when we are ready to switch from CONNECTING to CONNECTED_*,
do a connectivity check first, and switch to either CONNECTED_SITE or
CONNECTED_GLOBAL based on the result of that.
Build and use NMConnectivity regardless of build options; if you build
without libsoup, NMConnectivity will just always report that you have
full connectivity (like it does when you build with libsoup but don't
enable connectivity checking).
Before, whereever a connection id is accepted, the completion only
offered 'id', 'uuid', 'path', etc. With this change, it will additionally
suggest the id of existing connections.
https://bugzilla.redhat.com/show_bug.cgi?id=997997
Signed-off-by: Thomas Haller <thaller@redhat.com>
To support optimal completion, more context must be considered.
Especially the OPTIONS, which must appear before the OBJECT.
Modify bash completion to try parsing first the options.
Before, whenever you had options, completion did not work
anymore (because the object was expected as first argument).
Moreover, options were also suggested after specifying the
object. This is now mitigated by parsing the command line
in two steps.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This also slighly changes the behaviour for writing IPV6_DEFAULTGW.
- IPV6_DEFAULTGW will be written after IPV6ADDR and
IPV6ADDR_SECONDARY.
- Before, if there were no IPv6 addresse present, the IPV6_DEFAULTGW
might not have been cleared. Now IPV6_DEFAULTGW is always written
(or unset as in the case of gateway ::).
https://bugzilla.redhat.com/show_bug.cgi?id=997759
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, when a route failed to be added, NM stopped adding further
routes. However, the activation still continued and the user was not
notified about the error.
Adding a route might fail for example if the gateway is not on one of
the subnets of the interface.
Now, a failure to add a route makes the activaion fail. If the
connection has autoconnect=yes, this might result in some unsuccessful
reconnection attempts.
In the future, we might want to distinguish between manually added routes
and routes from RA/DHCP. So that connecting to a wrongly configured DHCP
server still works for most parts.
https://bugzilla.redhat.com/show_bug.cgi?id=999544
Signed-off-by: Thomas Haller <thaller@redhat.com>
These devices don't have a platform device at creation time, thus
is_software wasn't getting set properly. Move the is_software
decision to constructed() because by this point, the iface and
ifindex (if present) will be known for all cases and thus we can
figure out if it's a software device or not in one place.
The fix in commit b5b43a6d65 missed the
release of the route instance (because nm_setting_ip4_config_add_route
does not take over the passed route but duplicates it).
So the orginal error was to free the route with the wrong deallocation
method gs_unref_object instead of nm_ip4_route_unref.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This backwards compatible patch adds the possibility to use new
nm_device_generate_connection() API via update_connection() virtual
method implementations in NMDevice subclasses.
Compatibility is achieved by first trying to use the older API and
match_l2_config() virtual method and only then moving on to
update_connection().
The nm_device_generate_connection() calls update_connection() to create
type-specific NMSetting instances and verifies the connection before
returning it. To avoid tinkering with NMSettingConnection in
update_connection() we use a class attribute called connection_type
which is used by nm_device_generate_connection() itself.
Known issues:
* nm_device_generate_connection() method doesn't implement DHCP lease
configuration matching. We shouldn't actually need it but if a use case
for that will come out, we can fix it later.
* nm_device_generate_connection() doesn't fill in the slave-specific
options.
* update_connection() is not implemented and connection_type is not set
in the subclasses. This will be fixed in individual patches.
* NMSetting's compare_property() implementations in combination with
NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering
false negatives in some cases. Same as above.
Acked-by: Dan Winship <danw@gnome.org>
Acked-by: Thomas Haller <thaller@redhat.com>
Whether an active connection is assumed or connected from scratch is
only important during nm_device_activate(). When the activation process
is set up, there's no difference from any other active connection.
Acked-by: Dan Winship <danw@gnome.org>
Acked-by: Thomas Haller <thaller@redhat.com>
The link_changed method expects a valid info parameter.
NMDeviceMacvlan and NMDeviceGre calls link_changed
during construction for initialization.
As it was before, NMDeviceMacvlan and NMDeviceGre passed
NULL as NMPlatformLink, causing NM to segfault.
(Regression was introduced in 0e361e894c)
https://bugzilla.redhat.com/show_bug.cgi?id=997396
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
