Cache externally added IP details and represent them via the D-Bus
interface, and also merge them into the final device config to ensure
they aren't lost if DHCP renews or RA changes occur.
Routes without gateway are legal and should be treated as a device route
(direct route).
https://bugzilla.gnome.org/show_bug.cgi?id=697525
The original patch was written by Scott Shambarger <scott-gnome@shambarger.net>.
This is a modified version of the patch.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Reported-by: Scott Shambarger <scott-gnome@shambarger.net>
Since Debian 7 (Wheezy) / Ubuntu 11.04 (Natty Narwhal) ifupdown supports
the source stanza to source in other configuration files from
/etc/network/interfaces.
Add support to the ifupdown plugin to include configuration files via
source.
Patch did not apply cleanly and was slightly modified by Thomas Haller.
https://bugzilla.gnome.org/show_bug.cgi?id=707276
Signed-off-by: Thomas Haller <thaller@redhat.com>
Reviewed-by: Sebastian Harl <tokkee@debian.org>
Add a flag to indicate that the device is owned by NM.
This is interesting for software/virtual devices, that were created by
NM and should be deleted when the interface gets deactivated.
This flag is not implemented as a glib property.
Maybe this flag can be consolidated with the managed flag. For now it is
unclear how to do it, so add this flag. It should be easy later to
replace it again.
https://bugzilla.gnome.org/show_bug.cgi?id=695705https://bugzilla.redhat.com/show_bug.cgi?id=953300
Signed-off-by: Thomas Haller <thaller@redhat.com>
Old clients might expect 802-11-wireless.security being set for secured Wi-Fi
connections. So to be on a safer side, we set the property in D-Bus GetSettings()
result.
The manager has already disposed of the ActiveConnections by the time
the Policy is disposed, but the manager wasn't clearing the
active_connections list, so the Policy got a stale list of freed
objects. Next, the manager wasn't always emitting ACTIVE_CONNECTION_REMOVED
when disposing of ActiveConnections, which the Policy listens to
for cleanup. This lead to warnings on shutdown when the Policy
attempted to clean up for already disposed objects
Fix all this by ensuring the Manager signals when removing
ActiveConnections, which the Policy then uses to clean up
it's stuff, and ensuring the manager properly cleans up its
ActiveConnection list.
Calling g_file_test with a NULL path causes valgrind to complain.
NetworkManager[24512]: <debug> [1377884547.687536] [dhcp-manager/nm-dhcp-dhclient.c:482] create_dhclient_config(): (em1): no existing dhclient configuration to merge
==24512== Syscall param access(pathname) points to unaddressable byte(s)
==24512== at 0x3F976E7627: access (in /usr/lib64/libc-2.17.so)
==24512== by 0x4EDA556: g_file_test (in /usr/lib64/libglib-2.0.so.0.3600.3)
==24512== by 0x49BB69: create_dhclient_config (nm-dhcp-dhclient.c:364)
==24512== by 0x49CC39: ip4_start (nm-dhcp-dhclient.c:671)
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes a glib assertion.
Backtrace:
#0 0x00007f139ab08e0d in g_logv () from /lib64/libglib-2.0.so.0
#1 0x00007f139ab08ff2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x0000003f9aa3151a in g_type_check_instance () from /lib64/libgobject-2.0.so.0
#3 0x0000003f9aa272d4 in g_signal_handlers_disconnect_matched () from /lib64/libgobject-2.0.so.0
#4 0x0000000000495b7d in supplicant_interface_release (self=0xc58040) at devices/nm-device-wifi.c:423
#5 0x0000000000498a28 in dispose (object=0xc58040) at devices/nm-device-wifi.c:3525
#6 0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
#7 0x000000000047699a in remove_device (manager=manager@entry=0xc09050, device=0xc58040, quitting=quitting@entry=1) at nm-manager.c:748
#8 0x0000000000478a84 in dispose (object=0xc09050) at nm-manager.c:4558
#9 0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
#10 0x0000000000428cc0 in main (argc=1, argv=0x7fffc0948c98) at main.c:626
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes a glib assertion:
"dbus_g_proxy_cancel_call: assertion `pending != NULL' failed"
Backtrace:
#0 0x00007f962dad9e0d in g_logv () from /lib64/libglib-2.0.so.0
#1 0x00007f962dad9ff2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x00000000004a84bd in nm_secret_agent_cancel_secrets (self=0x213b300, call=0x1) at settings/nm-secret-agent.c:331
#3 0x00000000004a4068 in request_free (req=0x216a490) at settings/nm-agent-manager.c:479
#4 0x00007f962dac25fa in g_hash_table_remove_internal () from /lib64/libglib-2.0.so.0
Signed-off-by: Thomas Haller <thaller@redhat.com>
libgsystem contains more than just the local allocation macros; in the
future we will likely want to make use of some of this such as the
structured logging support.
Add *_to_string functions for address (ip4 and ip6) and
route (ip4 and ip6). Also refactor the previously existing
nm_platform_ip4_route_to_string function.
The to_string function returns a pointer to an internal
buffer. Also update log_* functions to make use of the new
to_string functions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add properties to track the "primary" connection (ie, the active
connection with either the default route, or the route to the VPN with
the default route), and the active connection that is currently
activating, and likely to become the :primary-connection when it
completes.
https://bugzilla.gnome.org/show_bug.cgi?id=704841
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).
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>
