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>
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
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.
The platform still needs to know about them, becuase the ethernet interface
is what gets configured and used for IP. But the Manager doens't want to
create a full new NMDevice for them, because there's already a Modem
device that "owns" that WWAN interface. So keep WWAN devices visible
to the platform, but just make the manager ignore them when creating
NMDevices.
Also, many WWAN pseduo-ethernet drivers set NOARP becuase they really
are point-to-point and thus ARP is pointless, and in this case, they
won't have any arptype of ARPHRD_ETHER. So determining the NMLinkType
from udev must take that into account.
Software devices don't have a UDI until udev finds them, and since we need
to know about the software devices before udev finds them the UDI will be
missing. Instead of requiring a UDI on NMDevice creation, update the
property from the NMPlatform link change signal when udev does find the
device.
Now that a UDI is no longer required for device creation, software devices
added by NM would be created in the platform_link_added_cb() signal
handler triggered by the various software device creation methods in
system_create_virtual_device() (eg nm_platform_bridge_add() etc). Then
the NMDevice created in system_create_virtual_device() would be a duplicate
and cause problems when it was added. Since system_create_virtual_device()
needs to do setup on some devices, suppress the device creation from the
platform link added handler in this function.
Much of this is a hack which should be cleaned up later.
The unref in finalize is not needed, because the hash table gets already freed
in dispose.
Note that setting available_connections to NULL in dispose is not really
needed, because (altough dispose might be called more than once) there
is a guarded by "priv->disposed = TRUE;". But leave it for clearity in
case somebody tries to access the pointer (which shouldn't happen).
Signed-off-by: Thomas Haller <thaller@redhat.com>
