fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-01-22 10:00:30 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/devices/nm-device.c

15007 lines
485 KiB
C
Raw Normal View History

2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
/* NetworkManager -- Network link manager
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
2008-06-26 Dan Williams <dcbw@redhat.com> * Update FSF address in license headers (Michael Biebl <biebl@debian.org>) git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3775 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-06-26 18:31:52 +00:00
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
* Copyright (C) 2005 - 2017 Red Hat, Inc.
2008-11-02 Dan Williams <dcbw@redhat.com> * Add license headers to everything in src/ git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4247 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-03 04:13:42 +00:00
* Copyright (C) 2006 - 2008 Novell, Inc.
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*/
all: cleanup includes and let "nm-default.h" include "config.h" - All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 14:57:48 +01:00
#include "nm-default.h"
all: consistently include config.h config.h should be included from every .c file, and it should be included before any other include. Fix that. (As a side effect of how I did this, this also changes us to consistently use "config.h" rather than <config.h>. To the extent that it matters [which is not much], quotes are more correct anyway, since we're talking about a file in our own build tree, not a system include.)
2014-11-13 10:07:02 -05:00
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
#include "nm-device.h"
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
#include <netinet/in.h>
#include <string.h>
Cleanup ioctl handling git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3458 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-14 20:37:48 +00:00
#include <unistd.h>
#include <errno.h>
#include <sys/ioctl.h>
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <arpa/inet.h>
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
#include <fcntl.h>
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
#include <linux/if_addr.h>
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
#include <linux/rtnetlink.h>
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
#include "nm-utils/nm-dedup-multi.h"
all: move NM_AUTH_PERMISSION_* defines to "nm-common-macros.h" header
2016-06-01 12:31:36 +02:00
#include "nm-common-macros.h"
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
#include "nm-device-private.h"
#include "NetworkManagerUtils.h"
core: track autoconnect for removed software devices (rh #1005913) When an interface is manually disconnected NM remembers that, and prevents automatic activation of the device. However, software devices are removed when they are disconnected, and thus the state of the device is lost. We need to track autoconnect outside the device - hash table of interface names not allowed to activate automatically. Without that the device would be auto-activated again and again, even if explicitly disconnected. Test case: $ nmcli con add type bond ifname bb con-name bb-con $ nmcli con add type bond-slave ifname em1 con-name b1-con master bb $ nmcli dev disconnect bb https://bugzilla.redhat.com/show_bug.cgi?id=1005913
2013-10-18 12:32:01 +02:00
#include "nm-manager.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "platform/nm-platform.h"
core: avoid cloning platform routes but iterate the cache directly
2017-06-29 15:19:35 +02:00
#include "platform/nmp-object.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "ndisc/nm-ndisc.h"
#include "ndisc/nm-lndp-ndisc.h"
#include "dhcp/nm-dhcp-manager.h"
core: rename "nm-activation-request.[hc]" for NMActRequest "nm-activation-request.[hc]" contains NMActRequest. It should thus be called "nm-act-request.[hc]".
2016-09-28 19:37:10 +02:00
#include "nm-act-request.h"
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
#include "nm-proxy-config.h"
core: fill in nm-types.h, clean out other headers Clean up some of the cross-includes between headers (which made it so that, eg, if you included NetworkManagerUtils.h in a test program, you would need to build the test with -I$(top_srcdir)/src/platform, and if you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all GObject struct definitions for src/ and src/settings/ into nm-types.h (which already existed to solve the NMDevice/NMActRequest circular references). Update various .c files to explicitly include the headers they used to get implicitly, and remove some now-unnecessary -I options from Makefiles.
2014-07-17 17:06:44 -04:00
#include "nm-ip4-config.h"
#include "nm-ip6-config.h"
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
#include "nm-pacrunner-manager.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "dnsmasq/nm-dnsmasq-manager.h"
2008-07-17 Dan Williams <dcbw@redhat.com> * introspection/Makefile.am introspection/nm-device.xml introspection/nm-dhcp4-config.xml - Add bits for the DHCP4Config property of the device, and the DHCP4Config itself * src/nm-device-interface.c src/nm-device-interface.h - Add the DHCP4Config property * src/nm-device.c - Keep track of DHCP4 options via a new DHCP4Config property and notify D-Bus clients when it changes * src/nm-dhcp4-config.c src/nm-dhcp4-config.h - Simple object to store DHCP4 options, export them over D-Bus, and notify when they change * src/dhcp-manager/nm-dhcp-manager.c src/dhcp-manager/nm-dhcp-manager.h - (nm_dhcp_manager_set_dhcp4_config, copy_dhcp4_config_option): copy and filter server-returned DHCP options into an NMDHCP4Config object git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3829 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-17 17:04:13 +00:00
#include "nm-dhcp4-config.h"
core: fill in nm-types.h, clean out other headers Clean up some of the cross-includes between headers (which made it so that, eg, if you included NetworkManagerUtils.h in a test program, you would need to build the test with -I$(top_srcdir)/src/platform, and if you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all GObject struct definitions for src/ and src/settings/ into nm-types.h (which already existed to solve the NMDevice/NMActRequest circular references). Update various .c files to explicitly include the headers they used to get implicitly, and remove some now-unnecessary -I options from Makefiles.
2014-07-17 17:06:44 -04:00
#include "nm-dhcp6-config.h"
core: split NMRfkillManager out of NMUdevManager Split the rfkill-monitoring parts of NMUdevManager into a separate class. Now NMUdevManager only handles device enumeration.
2013-05-09 10:24:08 -04:00
#include "nm-rfkill-manager.h"
firewall: add firewall manager src/firewall-manager tracks whether firewall is on the bus or not. In nm-device.c at stage5 (ip-config-commit) before we actually apply the IP configuration to the interface, we send the IP interface name and zone to firewall and asynchronously wait for a D-Bus reply. Then after we get the reply (or if the firewall isn't running) we proceed with applying the IP configuration to the interface.
2011-10-07 15:58:08 +02:00
#include "nm-firewall-manager.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "settings/nm-settings-connection.h"
#include "settings/nm-settings.h"
auth: rename file nm-manager-auth.* to nm-auth-utils.* Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-16 01:33:46 +02:00
#include "nm-auth-utils.h"
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
#include "nm-netns.h"
core: split dispatcher into its own file
2012-06-03 19:32:16 -05:00
#include "nm-dispatcher.h"
core: add ignore-carrier config option Add an ignore-carrier option to NetworkManager.conf, for specifying devices where carrier state should be ignored for purposes of activating/deactivating connections.
2013-03-19 10:24:35 -04:00
#include "nm-config.h"
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
#include "nm-utils/c-list.h"
build: don't add subdirectories to include search path but require qualified include Keep the include paths clean and separate. We use directories to group source files together. That makes sense (I guess), but then we should use this grouping also when including files. Thus require to #include files with their path relative to "src/". Also, we build various artifacts from the "src/" tree. Instead of having individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be unified. Previously, the CFLAGS for each artifact differ and are inconsistent in which paths they add to the search path. Fix the inconsistency by just don't add the paths at all.
2016-11-21 00:43:52 +01:00
#include "dns/nm-dns-manager.h"
core: don't use libnm-core private header outside of libnm-core/ Code outside of libnm-core/ should not include the private headers. nm-core-internal.h should be used instead. Fixes: 98fe073fb9d4a25ea41d5fee5eaf81259e5b6f00 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-10-27 21:12:07 +01:00
#include "nm-core-internal.h"
build: don't add systemd path the include search path Our internal copy of systemd should not be in the search path. Instead, let users only #include "systemd/nm-sd.h" which then includes everything from systemd that we need. We want to avoid to accidentally include anything from our systemd-copy. Any user of that should only include "nm-sd.h", which then includes everything that is needed further. For example, "src/devices/wwan/nm-modem-manager.c" has #include <systemd/nm-daemon.h> which in turn includes #include "_sd-common.h" This works all correctly before, because #include "" will first look in the directory where sd-daemon.h is. However, our mixing of external systemd library and internal copy is rather dangerous. Try to avoid it further by keeping the include paths clean.
2016-09-27 13:35:29 +02:00
#include "systemd/nm-sd.h"
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
#include "nm-lldp-listener.h"
device: add audit support
2015-07-14 10:19:19 +02:00
#include "nm-audit-manager.h"
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
#include "nm-arping-manager.h"
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
#include "nm-connectivity.h"
#include "nm-dbus-interface.h"
device: show better logging message when setting MTU fails Setting the MTU might fail when the underlying device's MTU is not set. Detect that case, and log a better warning message. Unfortunately, it's tricky to detect whether this is a complete failure, or whether we will later try again to change the MTU. So, we log a failure, altough later we might fix it. It would be better not to warn about non-errors.
2017-10-23 15:41:07 +02:00
#include "nm-device-vlan.h"
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
logging: extract logging macros for devices to nm-device-logging.h Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-02 14:52:49 +02:00
#include "nm-device-logging.h"
_LOG_DECLARE_SELF (NMDevice);
all: rename the introspection data to use the interface paths in names This makes it easier to install the files with proper names. Also, it makes the makefile rules slightly simpler. Lastly, the documentation is now generated into docs/api, which makes it possible to get rid of the awkward relative file names in docbook.
2016-11-23 13:14:08 +01:00
#include "introspection/org.freedesktop.NetworkManager.Device.h"
#include "introspection/org.freedesktop.NetworkManager.Device.Statistics.h"
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
device/trivial: reorder defines in "nm-device.c" Reorder code to be like in other source files: - first includes and generic defines - then various helper structs - then GObject related declarations, with first signal and property enums, then the private data, then the G_DEFINE_TYPE() itself. - finally, forward declarations for functions.
2017-02-02 12:38:35 +01:00
/*****************************************************************************/
core: move NMDeviceInterfaceError to nm-device.c
2011-11-18 00:05:37 -06:00
device/trivial: reorder defines in "nm-device.c" Reorder code to be like in other source files: - first includes and generic defines - then various helper structs - then GObject related declarations, with first signal and property enums, then the private data, then the G_DEFINE_TYPE() itself. - finally, forward declarations for functions.
2017-02-02 12:38:35 +01:00
#define DHCP_RESTART_TIMEOUT 120
#define DHCP_NUM_TRIES_MAX 3
#define DEFAULT_AUTOCONNECT TRUE
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
#define CARRIER_WAIT_TIME_MS 5000
#define CARRIER_WAIT_TIME_AFTER_MTU_MS 10000
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
#define NM_DEVICE_AUTH_RETRIES_UNSET -1
#define NM_DEVICE_AUTH_RETRIES_INFINITY -2
#define NM_DEVICE_AUTH_RETRIES_DEFAULT 3
device/trivial: reorder defines in "nm-device.c" Reorder code to be like in other source files: - first includes and generic defines - then various helper structs - then GObject related declarations, with first signal and property enums, then the private data, then the G_DEFINE_TYPE() itself. - finally, forward declarations for functions.
2017-02-02 12:38:35 +01:00
/*****************************************************************************/
typedef void (*ActivationHandleFunc) (NMDevice *self);
typedef struct {
ActivationHandleFunc func;
guint id;
} ActivationHandleData;
typedef enum {
CLEANUP_TYPE_KEEP,
CLEANUP_TYPE_REMOVED,
CLEANUP_TYPE_DECONFIGURE,
} CleanupType;
typedef enum {
IP_NONE = 0,
IP_WAIT,
IP_CONF,
IP_DONE,
IP_FAIL
} IpState;
typedef struct {
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
CList lst_slave;
device/trivial: reorder defines in "nm-device.c" Reorder code to be like in other source files: - first includes and generic defines - then various helper structs - then GObject related declarations, with first signal and property enums, then the private data, then the G_DEFINE_TYPE() itself. - finally, forward declarations for functions.
2017-02-02 12:38:35 +01:00
NMDevice *slave;
gulong watch_id;
bool slave_is_enslaved;
bool configure;
} SlaveInfo;
typedef struct {
NMDevice *device;
guint idle_add_id;
int ifindex;
} DeleteOnDeactivateData;
typedef void (*ArpingCallback) (NMDevice *, NMIP4Config **, gboolean);
typedef struct {
ArpingCallback callback;
NMDevice *device;
NMIP4Config **configs;
} ArpingData;
typedef enum {
HW_ADDR_TYPE_UNSET = 0,
HW_ADDR_TYPE_PERMANENT,
HW_ADDR_TYPE_EXPLICIT,
HW_ADDR_TYPE_GENERATED,
} HwAddrType;
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
typedef enum {
FIREWALL_STATE_UNMANAGED = 0,
FIREWALL_STATE_INITIALIZED,
FIREWALL_STATE_WAIT_STAGE_3,
FIREWALL_STATE_WAIT_IP_CONFIG,
} FirewallState;
device/trivial: reorder defines in "nm-device.c" Reorder code to be like in other source files: - first includes and generic defines - then various helper structs - then GObject related declarations, with first signal and property enums, then the private data, then the G_DEFINE_TYPE() itself. - finally, forward declarations for functions.
2017-02-02 12:38:35 +01:00
/*****************************************************************************/
core: move NMDeviceInterfaceError to nm-device.c
2011-11-18 00:05:37 -06:00
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
enum {
core: move state-changed signal to nm-device.c
2011-11-18 00:09:37 -06:00
STATE_CHANGED,
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
AUTOCONNECT_ALLOWED,
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
AUTH_REQUEST,
core: add device IPv4 and IPv6 config change signals We'll use these later to pull the DNS manager code out of the device class and into the policy.
2012-05-29 09:56:50 -05:00
IP4_CONFIG_CHANGED,
IP6_CONFIG_CHANGED,
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
IP6_PREFIX_DELEGATED,
IP6_SUBNET_NEEDED,
core: allow devices to indicate when they should be removed Devices created by plugins will use this to indicate when their backing resources have disappeared, at which point the manager should remove them.
2014-02-10 08:49:47 -06:00
REMOVED,
core: consolidate auto-activation recheck signals Add a generic signal that devices can use to indicate that something material in the network situation changed, and that auto-activation may now be possible. This reduces specific knowledge of device types in the policy.
2014-02-24 18:10:18 -06:00
RECHECK_AUTO_ACTIVATE,
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
RECHECK_ASSUME,
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
LAST_SIGNAL,
};
static guint signals[LAST_SIGNAL] = { 0 };
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
NM_GOBJECT_PROPERTIES_DEFINE (NMDevice,
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
PROP_UDI,
PROP_IFACE,
PROP_IP_IFACE,
PROP_DRIVER,
core: add driver-version, firmware-version properties to NMDevice (bgo #636124) The info is extracted via SIOCETHTOOL ioctl() syscall using ETHTOOL_GDRVINFO. This works for most drivers but not all, e.g. for modems. We may figure out how to get the info for specific devices, and enhance the solution by implementing specific functions for particular device types later.
2012-06-01 16:48:57 +02:00
PROP_DRIVER_VERSION,
PROP_FIRMWARE_VERSION,
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
PROP_CAPABILITIES,
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
PROP_CARRIER,
device: add 'mtu' property
2013-12-16 15:16:43 +01:00
PROP_MTU,
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
PROP_IP4_ADDRESS,
PROP_IP4_CONFIG,
PROP_DHCP4_CONFIG,
PROP_IP6_CONFIG,
PROP_DHCP6_CONFIG,
PROP_STATE,
core: add device property "StateReason" Allows clients to retrieve the reason a device changed to the given state along with the state itself, preventing race conditions if the state were retrieved separately from the reason. Reason codes were not previously accessible without listening to the StateChanged signal.
2012-01-29 22:40:37 +01:00
PROP_STATE_REASON,
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
PROP_ACTIVE_CONNECTION,
PROP_DEVICE_TYPE,
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
PROP_LINK_TYPE,
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
PROP_MANAGED,
core: add "Autoconnect" property to NMDevice It is bound to autoconnect_inhibit private variable (has opposite meaning). While 'Autoconnect' is TRUE (default value) the device can automatically activate a connection. If it is changed to FALSE, the device will not auto-activate until 'Autoconnect' is TRUE again. Disconnect() method sets 'Autoconnect' to FALSE. NMPolicy monitors the property and schedules auto activation when FALSE->TRUE transition is made.
2012-05-14 15:32:54 +02:00
PROP_AUTOCONNECT,
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
PROP_FIRMWARE_MISSING,
device: add nm-plugin-missing property indicating NM device plugin not available It is useful for indicating that the device type is supported but the required plugin is not installed.
2015-04-14 14:16:04 +02:00
PROP_NM_PLUGIN_MISSING,
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
PROP_TYPE_DESC,
PROP_RFKILL_TYPE,
PROP_IFINDEX,
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
PROP_AVAILABLE_CONNECTIONS,
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
PROP_PHYSICAL_PORT_ID,
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
PROP_MASTER,
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
PROP_PARENT,
core: reorganize hw-address properties Now that NMDevice reads the hwaddr directly from netlink, it's silly to have every device subtype maintain its own hw-address property (using data that it gets from the NMDevice base class). Remove all the device-specific hw-address properties, and add one to NMDevice instead. (Because of the way nm-properties-changed-signal works, this has no effect on the D-Bus API.) Subclasses now call nm_device_get_hw_address() in places where they used to just refer to priv->hw_addr (and to simplify this, we now allow passing NULL for the out length parameter, since the subclasses almost always know what the length will be already). Also reorganize/simplify a few other methods to take advantage of the fact that NMDevice is now keeping track of the hw-address directly. https://bugzilla.gnome.org/show_bug.cgi?id=699391
2013-05-01 09:28:16 -04:00
PROP_HW_ADDRESS,
device: implememnt "perm-hw-address" property in NMDevice Both NMDeviceEthernet and NMDeviceWifi have a property "perm-hw-address". As the hw_addr_perm property is tracked in the parent NMDevice class, let it also implement the GObject property. Then it knows better when to emit a notification about property changes.
2016-06-17 18:53:45 +02:00
PROP_PERM_HW_ADDRESS,
core: add NMManager:startup property 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.
2013-08-13 17:45:34 -04:00
PROP_HAS_PENDING_ACTION,
core,libnm: add 'metered' property to NMDevice
2015-04-29 16:34:38 +02:00
PROP_METERED,
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
PROP_LLDP_NEIGHBORS,
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
PROP_REAL,
device: implement slave property in parent device class Instead of reimplementing the slave property in bond, bridge and team, just add the property to the parent class. It's not that the parent class would be agnostic to the master/slave implementation, all the slaves are known to the every device type implementation. Also, the derived class doesn't know the correct time when to invoke the notify-changed for the slaves property. E.g. it should be only invoked after nm_device_slave_notify_enslave() when other components also consider the slave as enslaved. Later this will be fixed so that the SLAVES property correspond to what other master/slave related properties say.
2015-12-02 10:33:19 +01:00
PROP_SLAVES,
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
PROP_REFRESH_RATE_MS,
PROP_TX_BYTES,
PROP_RX_BYTES,
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
PROP_CONNECTIVITY,
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
);
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
device: cache pointer to private-data in NMDevice structure We often lookup the private data and retrieve it via NM_DEVICE_GET_PRIVATE(), which in turn calls G_TYPE_INSTANCE_GET_PRIVATE(). Instead cache the pointer to the private data. There are up- and downsides: - requries additional sizeof(gpointer) bytes for each NMDevice. + retrieving the private pointer will be slightly faster. + easier debugging in gdb as it is currently often a pain to retrieve the private data. But most importantly, the allows to change our common pattern to first cache the private data in a variable @priv. That is often cumbersome to write, especially for short functions. This change gives us a choice to use self->priv directly. Such a change should not be aimed for every class. Instead it makes mostly sense for NMDevice, where it pays off better due to the class' size and ubiquitous use. https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00017.html
2015-12-07 17:05:12 +01:00
typedef struct _NMDevicePrivate {
device: use "bool" type for fields in NMDevice Contrary to gboolean, bool is only one byte in size. Due to alignment and ordering of the fields, this saves merely 16 bytes per NMDevicePrivate struct (on x86_64), still. Also, bool is coerced by the compiler to be strictly FALSE or TRUE -- contrary to gboolean, which can be any integer. Thus, for bool type, "g_assert (NM_IN_SET (value, FALSE, TRUE));" never fails. That is desirable as well. While not a large win, it seems favorable to use bool type for fields of a struct.
2016-05-11 17:02:10 +02:00
bool in_state_changed;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
guint device_link_changed_id;
guint device_ip_link_changed_id;
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
NMDeviceState state;
core: add device property "StateReason" Allows clients to retrieve the reason a device changed to the given state along with the state itself, preventing race conditions if the state were retrieved separately from the reason. Reason codes were not previously accessible without listening to the StateChanged signal.
2012-01-29 22:40:37 +01:00
NMDeviceStateReason state_reason;
device: inline device helper structs QueuedState and PingInfo These two structs are only used at exactly one place: as the type for a field in NMDevicePrivate. Having additional structs (that are only used at one place) only add noise. Also, there are already prior-acts of using unnamed structs in NMDevicePrivate in case of structs that only serve to group/namespace a set of fields.
2017-02-02 12:28:32 +01:00
struct {
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
guint id;
/* The @state/@reason is only valid, when @id is set. */
device: inline device helper structs QueuedState and PingInfo These two structs are only used at exactly one place: as the type for a field in NMDevicePrivate. Having additional structs (that are only used at one place) only add noise. Also, there are already prior-acts of using unnamed structs in NMDevicePrivate in case of structs that only serve to group/namespace a set of fields.
2017-02-02 12:28:32 +01:00
NMDeviceState state;
NMDeviceStateReason reason;
} queued_state;
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
guint queued_ip4_config_id;
guint queued_ip6_config_id;
core: allow dynamic strings for pending action names Use a GSList of the string values, instead of an array of GQuarks. Using GQuarks does not allow to add arbitrary strings, because they would leak the internalized strings. The next patch will begin using unique, non-const action strings. Given the rather small number of expected pending states, a singly linked list seems appropriate. Signed-off-by: Thomas Haller <thaller@redhat.com> (some fixes and simplifications by dcbw based on patch reviews)
2013-12-16 16:52:36 +01:00
GSList *pending_actions;
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
GSList *dad6_failed_addrs;
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
NMDevice *parent_device;
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
char * udi;
char * iface; /* may change, could be renamed by user */
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
int ifindex;
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
int parent_ifindex;
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
int auth_retries;
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
union {
const guint8 hw_addr_len; /* read-only */
guint8 hw_addr_len_;
};
device: change hw_addr_type field to bitfield type We don't want to waste a full "int" size to store the @hw_addr_type in NMDevicePrivate. Previously, that was hacked around by using guint8. Now, instead use a bitfield which has the right type.
2017-02-02 12:34:30 +01:00
HwAddrType hw_addr_type:5;
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
bool real:1;
/* there was a IP config change, but no idle action was scheduled because device
* is still not platform-init */
bool queued_ip4_config_pending:1;
bool queued_ip6_config_pending:1;
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
char * ip_iface;
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
int ip_ifindex;
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
NMDeviceType type;
char * type_desc;
device: add nm_device_get_type_description() function Add a function to get a concise representation of the device type. libnm already has nm_device_get_type_description() for that and it is shown by nmcli -f GENERAL.TYPE device show Reimplement that function for nm-core. Just take care that the two implementations don't diverge.
2015-05-15 15:00:07 +02:00
char * type_description;
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
NMLinkType link_type;
device: use NMDeviceCapabilities enum for device capabilities
2015-04-17 15:15:38 +02:00
NMDeviceCapabilities capabilities;
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
char * driver;
core: add driver-version, firmware-version properties to NMDevice (bgo #636124) The info is extracted via SIOCETHTOOL ioctl() syscall using ETHTOOL_GDRVINFO. This works for most drivers but not all, e.g. for modems. We may figure out how to get the info for specific devices, and enhance the solution by implementing specific functions for particular device types later.
2012-06-01 16:48:57 +02:00
char * driver_version;
char * firmware_version;
core: better matching of rfkill types This also fixes a bug where WWAN devices were not correctly recognized for enable/disable operations.
2010-03-25 11:36:19 -07:00
RfKillType rfkill_type;
device: only set permanent hardware address once While a device is realized, we only want to read the permanent MAC address once. If that fails, we fallback to the current MAC address. Thus, we want the permanent address be stable until the device unrealizes. While we want to fallback to the current MAC address, in some cases the caller wants to know whether this was a "real" permanent MAC address as read via ethtool. For example, when matching an ethernet device against ethernet.mac-address property, the fake (current) address should not be used in such case.
2016-05-20 13:47:23 +02:00
bool firmware_missing:1;
bool nm_plugin_missing:1;
bool hw_addr_perm_fake:1; /* whether the permanent HW address could not be read and is a fake */
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
NMUtilsStableType current_stable_id_type:3;
device: rename priv->is_nm_owned to priv->nm_owned Only a matter of taste, but nm_device_get_is_nm_owned() sounds strange.
2017-05-31 16:42:05 +02:00
bool nm_owned:1; /* whether the device is a device owned and created by NM */
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
bool assume_state_guess_assume:1;
char * assume_state_connection_uuid;
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
GHashTable * available_connections;
core: update data types of some hwaddr properties Now that we have nm_utils_hwaddr_matches() for comparing addresses (even when one is a string and the other binary), there are now places where it's more convenient to store hardware addresses as strings rather than binary, since we want them in string form for most non-comparison purposes. So update for that. In particular, this also changes nm_device_get_hw_address() to return a string. Also, simplify the update_permanent_hw_address() implementations by assuming that they will only be called once. (Since they will.)
2014-06-21 12:44:56 -04:00
char * hw_addr;
device/trivial: rename hw-addr related fields in NMDevicePrivate Next I will add two more fields. Being able to efficiently grep the code is important. I want to be able to grep for "->hw_addr" or "\<hw_addr" to find related stuff. Unfortunately, prefixes often result in backward English names, e.g. hw_addr_set/hw_addr_get. I still prefer that over get_hw_addr/set_hw_addr though.
2016-06-03 13:37:08 +02:00
char * hw_addr_perm;
char * hw_addr_initial;
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
char * physical_port_id;
core: use dev_id when calculating the interface IPv6 IID (rh #1101809) Some device types (s390 OSA and ipvlan) can use the same link-layer address for multiple virtual interfaces, and the kernel used the dev_id property to differentiate these devices when constructing the IID. NM should do this too to prevent IID clashes. https://bugzilla.redhat.com/show_bug.cgi?id=1101809
2015-03-24 12:46:18 -05:00
guint dev_id;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
NMUnmanagedFlags unmanaged_mask;
core: convert unmanaged bits to flags Instead of tracking unmanaged-ness in a couple variables (and because I'd like to add one for user-unmanaged later) let's do it in a single flags variable, and consolidate setting of the unmanaged states in one place.
2014-03-31 21:45:54 -05:00
NMUnmanagedFlags unmanaged_flags;
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
DeleteOnDeactivateData *delete_on_deactivate_data; /* data for scheduled cleanup when deleting link (g_idle_add) */
core: add a "default-unmanaged" setting for devices Allow devices to declare themselves unmanaged-by-default, but tweak nm-manager and nm-policy to allow activating matching connections on those devices anyway. (This ensures that NM keeps its hands completely off the device unless the user explicitly asks it to do something with it.)
2013-04-24 10:40:58 -04:00
device: new deactivate_async() method to be run during DEACTIVATING phase This method isn't run if NM is quitting; so the deactivate() method still needs to be implemented to handle sync disconnection requests.
2014-08-05 20:08:34 +02:00
GCancellable *deactivating_cancellable;
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
guint32 ip4_address;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
NMActRequest * queued_act_request;
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
bool queued_act_request_is_waiting_for_carrier:1;
bool act_request_public:1;
NMActRequest *act_request;
gulong act_request_id;
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
ActivationHandleData act_handle4; /* for layer2 and IPv4. */
ActivationHandleData act_handle6;
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
guint recheck_assume_id;
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
struct {
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
guint call_id;
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
NMDeviceStateReason available_reason;
NMDeviceStateReason unavailable_reason;
} recheck_available;
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
struct {
guint call_id;
NMDeviceState post_state;
NMDeviceStateReason post_state_reason;
} dispatcher;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
/* Link stuff */
guint link_connected_id;
guint link_disconnected_id;
guint carrier_defer_id;
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
guint carrier_wait_id;
device: re-apply sriov_numvfs after SIGHUP
2017-04-14 17:46:20 +02:00
gulong config_changed_id;
device: add 'mtu' property
2013-12-16 15:16:43 +01:00
guint32 mtu;
device: cleanup setting of mtu in NMDevice Mark priv->mtu/priv->ip_mtu/ priv->ip6_mtu as const to highlight the places that explicitly set their mutable aliases priv->mtu_/ priv->ip_mtu_/priv->ip6_mtu_. Also, NM_DEVICE_MTU property is read-only. It cannot be set via g_object_set(). Also, clear priv->mtu in nm_device_unrealize().
2017-01-13 15:55:48 +01:00
guint32 ip6_mtu;
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
guint32 mtu_initial;
guint32 ip6_mtu_initial;
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
guint32 v4_route_table;
guint32 v6_route_table;
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
/* when carrier goes away, we give a grace period of CARRIER_WAIT_TIME_MS
* until taking action.
*
* When changing MTU, the device might take longer then that. So, whenever
* NM changes the MTU it sets @carrier_wait_until_ms to CARRIER_WAIT_TIME_AFTER_MTU_MS
* in the future. This is used to extend the grace period in this particular case. */
gint64 carrier_wait_until_ms;
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
bool carrier:1;
bool ignore_carrier:1;
device: set a per-device default MTU on activation In absence of an explicit MTU (either via user configuration, PPP or DHCP), set a default MTU on activation that depends on the device type. We only want to do that on the very first call to _commit_mtu(). Later calls (for example in response to new DHCP leases) skip over this step. This means, on activation the MTU will always be reset to a sensible value instead of preserving whatever was left from a previous configuration. This does not cover setting the MTU from the VPN plugin :(
2017-01-16 12:18:51 +01:00
bool mtu_initialized:1;
bool up:1; /* IFF_UP */
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
device: on reapply reset commit_first_time flag Based on this flag, we decide that: - if we are not gonna commit the first time and the connection is configured with never-default, we would not remove a default route added externally. During a reapply, we however want to get rid of an externally configured default route.
2017-03-16 14:37:54 +01:00
bool v4_commit_first_time:1;
bool v6_commit_first_time:1;
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
bool default_route_metric_penalty_ip4_has:1;
bool default_route_metric_penalty_ip6_has:1;
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
NMDeviceSysIfaceState sys_iface_state:2;
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
bool v4_route_table_initalized:1;
bool v6_route_table_initalized:1;
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
NMDeviceAutoconnectBlockedFlags autoconnect_blocked_flags:4;
core: rename some DHCPv4 specific variables
2010-01-13 18:06:05 -08:00
/* Generic DHCP stuff */
libnm-core: change all mac-address properties to G_TYPE_STRING Make all mac-address properties (including NMSettingBluetooth:bdaddr, NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be strings, using _nm_setting_class_transform_property() to handle translating to/from binary form when dealing with D-Bus. Update everything accordingly for the change, and also add a test for transformed setting properties to test-general.
2014-07-30 10:57:45 -04:00
char * dhcp_anycast_address;
core: simplify DHCP setup and cleanup nm_device_set_use_dhcp() and nm_device_get_use_dhcp() were somewhat confusing and don't really reflect the new DHCP architecture with NMDHCPClient. Now that timeout and state signals are specific to the NMDHCPClient it doesn't make sense to check for DHCP use in the callbacks for those signals since they'll never get called if DHCP isn't in use. We might as well just keep the DHCP manager around and check whether a DHCP client instance exists when we need to figure out whether DHCP is in use.
2010-01-13 17:59:54 -08:00
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
char * current_stable_id;
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
/* Proxy Configuration */
proxy: reorder parts in nm-proxy-config.c and nm-pacrunner-manager.c
2016-10-04 11:58:32 +02:00
NMProxyConfig *proxy_config;
proxy: rename NMPacRunnerManager to NMPacrunnerManager The names NMPacRunnerManager, nm_pac_runner_manager were inconsistent with NM_PACRUNNER_MANAGER and nm-pacrunner-manager.[hc]. They should be consistent. It seems pacrunner project calls itself "PACrunner" or just "pacrunner", so prefer the spelling with lower-case 'r'.
2016-10-04 12:13:16 +02:00
NMPacrunnerManager *pacrunner_manager;
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
NMPacrunnerCallId *pacrunner_call_id;
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
/* IP4 configuration info */
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
NMIP4Config * ip4_config; /* Combined config from VPN, settings, and device */
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
union {
const IpState ip4_state;
IpState ip4_state_;
};
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
NMIP4Config * con_ip4_config; /* config from the setting */
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
NMIP4Config * dev_ip4_config; /* Config from DHCP, PPP, LLv4, etc */
core: fix handling of externally added IPv4 adresses and routes on IP change The switch to combine IPv4 configs to arrive at the final config would cause externally added addresses and routes to be removed from the interface when a DHCP or LLv4 event came in, becasue the externally added details weren't cached anywhere and thus would be dropped on the IP changes.
2013-08-01 15:44:53 -05:00
NMIP4Config * ext_ip4_config; /* Stuff added outside NM */
wwan: split out WWAN IP4Config from device config We want to set the WWAN config last, to ensure that the configuration we use overwrites anything that pppd might have set, becuase it touches some stuff itself. That means we have to keep the WWAN config separate, since dev_ip4_config is used for DHCP and IPv4LL, which we always set first to ensure they these don't overwrite external, administrator added config (eg, priv->ext_ip4_config). This also synchronizes the IPv4 config path with the upcoming IPv6 config path.
2014-07-15 17:16:56 -05:00
NMIP4Config * wwan_ip4_config; /* WWAN configuration */
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
GSList * vpn4_configs; /* VPNs which use this device */
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
device: apply a loose IPv4 rp_filter when it would interfere with multihoming The IPv4 Strict Reverse Path Forwarding filter (RFC 3704) drops legitimate traffic when the same route is present on multiple interfaces, which is a pretty common scenario for IPv4 hosts. In particular, if the traffic is routable via multiple interfaces it drops traffic incoming via the device that has lower metric on the route to the originating network. Among other things, this disrupts existing connection when the user connected to the Internet via Wi-Fi activates a Wired Ethernet connection that also has a default route. Also, the Strict filter (and Reverse Path filters in general) provide practically no value to hosts that have a default route. The solution this patch uses is to detect scenarios where Strict filter is known to interfere and switch to a saner RP filter on the affected links. Routes to the same network on multiple interfaces is a good indication the RP filter would drop the legitimate traffice from the link with a lower metric. This includes the default routes. In such cases, we switch to the Loose Reverse Path Forwarding. This addresses the problems the multihomed hosts face, at the cost of disabling filtering altogether when a default route is present. A Feasible Path Reverse Path Forwarding would address the main problems with the Strict filter, but it's not implemented by the Linux kernel.
2017-03-16 14:27:03 +00:00
bool v4_has_shadowed_routes;
const char *ip4_rp_filter;
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
/* DHCPv4 tracking */
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
struct {
NMDhcpClient * client;
gulong state_sigid;
NMDhcp4Config * config;
guint restart_id;
device: retry DHCPv4 when a lease expires Make DHCPv4 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:00:47 +02:00
guint num_tries_left;
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
char * pac_url;
device: fix behavior for assumed DHCP connections When a DHCP connection is active and the DHCP server is temporarily unreachable, we restart DHCP for some times before failing the connection. From the user point of view, restarting NM (and thus assuming the existing connection) should not change this behavior. However, if NM is restarted while the server is temporarily down, at the moment we immediately fail because we consider the DHCP transaction our first try. Fix this by restoring the multiple tries when we detect that DHCP was active before because the connection is assumed.
2017-05-04 10:05:25 +02:00
bool was_active;
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
} dhcp4;
2008-05-29 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (dnsmasq_state_changed_cb): new function; fail the connection if something happens to dnsmasq - (nm_device_new_ip4_shared_config): new function; create a new ip4-config for shared connections. Shared connections always use a fixed static IP address. - (real_act_stage4_get_ip4_config): handle shared connections; fix autoip connections by actually using the returned ip4-config and not leaking it - (nm_device_activate_stage5_ip_config_commit): start dnsmasq for shared connections - (nm_device_deactivate_quickly, nm_device_dispose): terminate dnsmasq if its active git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3711 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-29 20:58:52 +00:00
device: inline device helper structs QueuedState and PingInfo These two structs are only used at exactly one place: as the type for a field in NMDevicePrivate. Having additional structs (that are only used at one place) only add noise. Also, there are already prior-acts of using unnamed structs in NMDevicePrivate in case of structs that only serve to group/namespace a set of fields.
2017-02-02 12:28:32 +01:00
struct {
NMLogDomain log_domain;
guint timeout;
guint watch;
GPid pid;
const char *binary;
const char *address;
guint deadline;
} gw_ping;
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
/* dnsmasq stuff for shared connections */
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
NMDnsMasqManager *dnsmasq_manager;
gulong dnsmasq_state_id;
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
core: use singleton nm_firewall_manager_get() throughout without taking additional ref No need to keep references of the singleton and take an additional ref when accessing nm_firewall_manager_get(). Especially, since the firewall manager instance was nowhere passed in from externally, it doesn't even sense for some vague testing purporse. Not to mention, that there are no tests that actually inject a firewall manager stub. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-02 15:19:58 +02:00
/* Firewall */
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
FirewallState fw_state:4;
NMFirewallManager *fw_mgr;
firewall/trivial: rename NMFirewallPendingCall to NMFirewallManagerCallId Matches the naming scheme for other call-ids.
2015-09-23 16:41:14 +02:00
NMFirewallManagerCallId fw_call;
firewall: add firewall manager src/firewall-manager tracks whether firewall is on the bus or not. In nm-device.c at stage5 (ip-config-commit) before we actually apply the IP configuration to the interface, we send the IP interface name and zone to firewall and asynchronously wait for a D-Bus reply. Then after we get the reply (or if the firewall isn't running) we proceed with applying the IP configuration to the interface.
2011-10-07 15:58:08 +02:00
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
/* IPv4LL stuff */
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
sd_ipv4ll * ipv4ll;
guint ipv4ll_timeout;
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
guint rt6_temporary_not_available_id;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
/* IPv4 DAD stuff */
struct {
GSList * dad_list;
NMArpingManager * announcing;
} arping;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
/* IP6 configuration info */
Add NMIP6Manager to handle IPv6 addrconf Automatic IPv6 configuration is handled by the kernel, but to integrate it properly with NetworkManager, we need to watch what the kernel does to see whether or not it was successful (so that we can let the user know if there is no IPv6 router present, for example). NMIP6Manager takes care of this.
2009-07-30 13:50:42 -04:00
NMIP6Config * ip6_config;
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
union {
const IpState ip6_state;
IpState ip6_state_;
};
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
NMIP6Config * con_ip6_config; /* config from the setting */
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
NMIP6Config * wwan_ip6_config;
core: handle externally added IPv6 adresses and routes on IP change 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.
2013-08-15 12:55:56 -05:00
NMIP6Config * ext_ip6_config; /* Stuff added outside NM */
device: add ext_ip6_config_captured to remember the last-read platform configuration ext_ip6_config gets modified to only contain items that are configured externally, not by internal choice.
2016-01-30 21:37:22 +01:00
NMIP6Config * ext_ip6_config_captured; /* Configuration captured from platform. */
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
GSList * vpn6_configs; /* VPNs which use this device */
device: use "bool" type for fields in NMDevice Contrary to gboolean, bool is only one byte in size. Due to alignment and ordering of the fields, this saves merely 16 bytes per NMDevicePrivate struct (on x86_64), still. Also, bool is coerced by the compiler to be strictly FALSE or TRUE -- contrary to gboolean, which can be any integer. Thus, for bool type, "g_assert (NM_IN_SET (value, FALSE, TRUE));" never fails. That is desirable as well. While not a large win, it seems favorable to use bool type for fields of a struct.
2016-05-11 17:02:10 +02:00
bool nm_ipv6ll; /* TRUE if NM handles the device's IPv6LL address */
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
NMIP6Config * dad6_ip6_config;
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
GHashTable * rt6_temporary_not_available;
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
NMNDisc * ndisc;
gulong ndisc_changed_id;
gulong ndisc_timeout_id;
NMSettingIP6ConfigPrivacy ndisc_use_tempaddr;
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
/* IP6 config from autoconf */
NMIP6Config * ac_ip6_config;
core: implement manual disconnect feature In the past networkmanager did not allow to manually disconnect devices. Manually disconnected devices will not be automatically reconnected until one of the following events occur: 1. user activates a connection for the currently disconnected device 2. network manager awakes from hibernate/suspend 3. network manager is restarted (e.g. reboot) Add a Disconnect method to generic NMDevice dbus interface; set a new private autoconnect_inhibit flag if Disconnect method is called through dbus. Based on this auto activation for devices gets inhibited until one of the above events occur.
2009-09-16 13:18:24 +02:00
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
guint linklocal6_timeout_id;
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
guint8 linklocal6_dad_counter;
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
devices: abstract the handling of IPv6 sysfs properties We're about to start using a bunch more IPv6 sysfs properties, so let's start by making the code more extensible.
2014-02-21 17:04:59 -05:00
GHashTable * ip6_saved_properties;
core: add support for IPv6 Privacy Extensions for SLAAC (RFC4941) (bgo #633233)
2012-02-21 15:44:19 +01:00
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
struct {
NMDhcpClient * client;
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
NMNDiscDHCPLevel mode;
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
gulong state_sigid;
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
gulong prefix_sigid;
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
NMDhcp6Config * config;
/* IP6 config from DHCP */
NMIP6Config * ip6_config;
/* Event ID of the current IP6 config from DHCP */
char * event_id;
guint restart_id;
device: retry DHCPv6 when a lease expires Make DHCPv6 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:09:54 +02:00
guint num_tries_left;
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
guint needed_prefixes;
device: fix behavior for assumed DHCP connections When a DHCP connection is active and the DHCP server is temporarily unreachable, we restart DHCP for some times before failing the connection. From the user point of view, restarting NM (and thus assuming the existing connection) should not change this behavior. However, if NM is restarted while the server is temporarily down, at the moment we immediately fail because we consider the DHCP transaction our first try. Fix this by restoring the multiple tries when we detect that DHCP was active before because the connection is assumed.
2017-05-04 10:05:25 +02:00
bool was_active;
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
} dhcp6;
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
gboolean needs_ip6_subnet;
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
/* master interface for bridge/bond/team slave */
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
NMDevice * master;
device: use "bool" type for fields in NMDevice Contrary to gboolean, bool is only one byte in size. Due to alignment and ordering of the fields, this saves merely 16 bytes per NMDevicePrivate struct (on x86_64), still. Also, bool is coerced by the compiler to be strictly FALSE or TRUE -- contrary to gboolean, which can be any integer. Thus, for bool type, "g_assert (NM_IN_SET (value, FALSE, TRUE));" never fails. That is desirable as well. While not a large win, it seems favorable to use bool type for fields of a struct.
2016-05-11 17:02:10 +02:00
bool is_enslaved;
bool master_ready_handled;
core: always use gulong to store signal handler ids We inconsistently use gulong,guint,int types to store signal handler id, but the type returned by g_signal_connect() is a gulong. This has no practical consequences because a int/guint is enough to store the value, however it is better to use a consistent type, also because nm_clear_g_signal_handler() accepts a pointer to the signal id and thus it must be always called with the same pointer type.
2016-01-04 10:29:06 +01:00
gulong master_ready_id;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
core: add IS_MASTER property to NMDevice We can't just check whether there are slaves or not, because the master device may be started before any slaves exist, and the slaves get added later.
2013-01-24 17:47:59 -06:00
/* slave management */
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
CList slaves; /* list of SlaveInfo */
core: pass connection provider to devices
2012-05-02 10:28:16 -05:00
core,libnm: add 'metered' property to NMDevice
2015-04-29 16:34:38 +02:00
NMMetered metered;
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
NMSettings *settings;
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
NMNetns *netns;
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
NMLldpListener *lldp_listener;
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
NMConnectivityState connectivity_state;
guint concheck_periodic_id;
guint64 concheck_seq;
device: remove unrealized device without connections on idle handler Emitting the NM_DEVICE_REMOVED signal can cause the destruction of the device, thus it should be emitted on an idle handler.
2016-01-19 11:33:33 +01:00
guint check_delete_unrealized_id;
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
device: namespace fields related to statistics in NMDevicePrivate ... by grouping them together in a struct.
2016-08-16 11:35:23 +02:00
struct {
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
guint timeout_id;
device: namespace fields related to statistics in NMDevicePrivate ... by grouping them together in a struct.
2016-08-16 11:35:23 +02:00
guint refresh_rate_ms;
guint64 tx_bytes;
guint64 rx_bytes;
} stats;
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
} NMDevicePrivate;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device/trivial: reorder defines in "nm-device.c" Reorder code to be like in other source files: - first includes and generic defines - then various helper structs - then GObject related declarations, with first signal and property enums, then the private data, then the G_DEFINE_TYPE() itself. - finally, forward declarations for functions.
2017-02-02 12:38:35 +01:00
G_DEFINE_ABSTRACT_TYPE (NMDevice, nm_device, NM_TYPE_EXPORTED_OBJECT)
#define NM_DEVICE_GET_PRIVATE(self) _NM_GET_PRIVATE_PTR(self, NMDevice, NM_IS_DEVICE)
/*****************************************************************************/
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
static void nm_device_set_proxy_config (NMDevice *self, const char *pac_url);
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
static gboolean update_ext_ip_config (NMDevice *self, int addr_family, gboolean initial, gboolean intersect_configs);
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
static gboolean nm_device_set_ip4_config (NMDevice *self,
core: implement connection assumption Mark activation requests that contain connections to be assumed, and use that to short-circuit various parts of the activation process by not touching various device attributes, since they are already set up. Also ensure the device is not deactivated when it initially becomes managed, because that would kill the connection we are about to assume.
2009-08-05 18:03:09 -04:00
NMIP4Config *config,
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
gboolean commit,
GPtrArray *ip4_dev_route_blacklist);
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
static gboolean ip4_config_merge_and_apply (NMDevice *self,
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
gboolean commit);
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
static gboolean nm_device_set_ip6_config (NMDevice *self,
core: implement connection assumption Mark activation requests that contain connections to be assumed, and use that to short-circuit various parts of the activation process by not touching various device attributes, since they are already set up. Also ensure the device is not deactivated when it initially becomes managed, because that would kill the connection we are about to assume.
2009-08-05 18:03:09 -04:00
NMIP6Config *config,
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
gboolean commit);
device: restore IP configuration when link comes up This is especially important, because changing MTU takes the link down for a moment. Taking a link down deletes IP routes and IPv6 addresses. Thus, when the link comes up again, we must restore them. Otherwise, we don't call merge_and_apply() until the next DHCP lease (or possibly never in case of static addressing). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-04-15 20:01:36 +02:00
static gboolean ip6_config_merge_and_apply (NMDevice *self,
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
gboolean commit);
2008-11-07 Dan Williams <dcbw@redhat.com> Fix deletion of VPN gateway route on DHCP renew (bgo #558133) * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_ip4_route): return the route that was added - (nm_system_add_ip4_vpn_gateway_route): make add_vpn_gateway_route() public, clean up, and return the route that was added - (nm_system_apply_ip4_config): remove VPN related stuff to simplify, since nm_system_add_ip4_vpn_gateway_route() is now available; add flags to allow only certain attributes of the NMIP4Config to be applied * src/nm-device.c - (handle_dhcp_lease_change): don't touch the DHCP4 config on failure - (nm_device_set_ip4_config): use nm_ip4_config_diff() to only apply what's really changed between the old and new configs; don't export the new IP4 config on failure; always send the DNS info to the named manager * src/vpn-manager/nm-vpn-connection.c - (device_ip4_config_changed, nm_vpn_connection_new, dispose): track the parent device's IP4Config and re-add the VPN gateway route when it changes - (nm_vpn_connection_ip4_config_get): add the VPN gateway route (since nm_system_apply_ip4_config() no longer does) and cache it for later - (connection_state_changed): move cleanup code to its own function - (vpn_cleanup): delete any previously added VPN gateway route; and re-apply the parent device's addresses and routes using nm_system_apply_ip4_config(), not nm_device_set_ip4_config() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4277 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-07 13:57:39 +00:00
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
static gboolean nm_device_master_add_slave (NMDevice *self, NMDevice *slave, gboolean configure);
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
static void nm_device_slave_notify_enslave (NMDevice *self, gboolean success);
static void nm_device_slave_notify_release (NMDevice *self, NMDeviceStateReason reason);
core: print textual description for reason codes on device deactivation too
2011-09-19 14:19:53 +02:00
core: fail IPv6 router discovery if IID cannot be generated If the IID cannot be generated, the IPv6 address resulting from the combination of an advertised prefix and 64-bits of zero is both wrong and quite likely to clash with some other machine on the network that doesn't implement IPv6 quite right either. Require an valid interface identifier. If NetworkManager doesn't know how to generate one, then we should fix NM to do so.
2014-07-22 16:24:07 -05:00
static gboolean addrconf6_start_with_link_ready (NMDevice *self);
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
static NMActStageReturn linklocal6_start (NMDevice *self);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
static void _carrier_wait_check_queued_act_request (NMDevice *self);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static const char *_activation_func_to_string (ActivationHandleFunc func);
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
static void activation_source_handle_cb (NMDevice *self, int addr_family);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
static void _set_state_full (NMDevice *self,
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
NMDeviceState state,
NMDeviceStateReason reason,
gboolean quitting);
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
static void queued_state_clear (NMDevice *device);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
static gboolean queued_ip4_config_change (gpointer user_data);
static gboolean queued_ip6_config_change (gpointer user_data);
device: trivial: group all forward declarations of static functions
2016-03-09 15:04:11 +01:00
static void ip_check_ping_watch_cb (GPid pid, gint status, gpointer user_data);
static gboolean ip_config_valid (NMDeviceState state);
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
static NMActStageReturn dhcp4_start (NMDevice *self);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
static gboolean dhcp6_start (NMDevice *self, gboolean wait_for_ll);
device: trivial: group all forward declarations of static functions
2016-03-09 15:04:11 +01:00
static void nm_device_start_ip_check (NMDevice *self);
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
static void realize_start_setup (NMDevice *self,
const NMPlatformLink *plink,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
gboolean assume_state_guess_assume,
const char *assume_state_connection_uuid,
device: only set nm-owned from statefile during initial setup The state file should only be read initially when NM starts, that is: during NMManager's platform_query_devices(). At all later points, for example when a software device gets destroyed and re-realized, the state file is clearly no longer relevant. Hence, pass the set-nm-owned flag from NMManager to realize_start_setup(). This is very much the same as with the NM_UNMANAGED_FLAG_USER_EXPLICT flag, which we also read from the state-file.
2017-06-07 22:11:50 +02:00
gboolean set_nm_owned,
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
NMUnmanFlagOp unmanaged_user_explicit);
device: set MTU property of device in new _set_mtu() function
2017-10-13 13:11:11 +02:00
static void _set_mtu (NMDevice *self, guint32 mtu);
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
static void _commit_mtu (NMDevice *self, const NMIP4Config *config);
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
static void dhcp_schedule_restart (NMDevice *self, int addr_family, const char *reason);
device: cancel pending activation when slave is released Since nm_device_slave_notify_release() is called from outside the activation chain of the slave device (it gets called from the master device) there might be pending activation sources scheduled, clear them before queueing a state change.
2016-06-28 14:12:57 +02:00
static void _cancel_activation (NMDevice *self);
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
device: implement queued_state_to_string() via NM_UTILS_LOOKUP_STR_DEFINE_STATIC()
2017-01-27 14:13:09 +01:00
NM_UTILS_LOOKUP_STR_DEFINE_STATIC (queued_state_to_string, NMDeviceState,
NM_UTILS_LOOKUP_DEFAULT ( NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "???"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_UNKNOWN, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "unknown"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_UNMANAGED, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "unmanaged"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_UNAVAILABLE, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "unavailable"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_DISCONNECTED, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "disconnected"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_PREPARE, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "prepare"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_CONFIG, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "config"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_NEED_AUTH, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "need-auth"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_IP_CONFIG, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "ip-config"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_IP_CHECK, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "ip-check"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_SECONDARIES, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "secondaries"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_ACTIVATED, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "activated"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_DEACTIVATING, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "deactivating"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_FAILED, NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE "failed"),
);
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
const char *
nm_device_state_to_str (NMDeviceState state)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
return queued_state_to_string (state) + NM_STRLEN (NM_PENDING_ACTIONPREFIX_QUEUED_STATE_CHANGE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
utils: pass entire return statement to NM_UTILS_LOOKUP_DEFINE()
2016-02-01 14:09:56 +01:00
NM_UTILS_LOOKUP_STR_DEFINE_STATIC (_reason_to_string, NMDeviceStateReason,
NM_UTILS_LOOKUP_DEFAULT (NULL),
core/trivial: rename NM_UTILS_STRING_LOOKUP_TABLE* to NM_UTILS_LOOKUP* Due to using a switch stetement, it is no longer only useful for looking up strings, and it certainly doesn't use a table anymore.
2016-01-24 14:28:31 +01:00
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_UNKNOWN, "unknown"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_NONE, "none"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_NOW_MANAGED, "managed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_NOW_UNMANAGED, "unmanaged"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_CONFIG_FAILED, "config-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE, "ip-config-unavailable"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_IP_CONFIG_EXPIRED, "ip-config-expired"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_NO_SECRETS, "no-secrets"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SUPPLICANT_DISCONNECT, "supplicant-disconnect"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SUPPLICANT_CONFIG_FAILED, "supplicant-config-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SUPPLICANT_FAILED, "supplicant-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SUPPLICANT_TIMEOUT, "supplicant-timeout"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_PPP_START_FAILED, "ppp-start-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_PPP_DISCONNECT, "ppp-disconnect"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_PPP_FAILED, "ppp-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_DHCP_START_FAILED, "dhcp-start-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_DHCP_ERROR, "dhcp-error"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_DHCP_FAILED, "dhcp-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SHARED_START_FAILED, "sharing-start-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SHARED_FAILED, "sharing-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_AUTOIP_START_FAILED, "autoip-start-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_AUTOIP_ERROR, "autoip-error"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_AUTOIP_FAILED, "autoip-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_BUSY, "modem-busy"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_NO_DIAL_TONE, "modem-no-dialtone"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_NO_CARRIER, "modem-no-carrier"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_DIAL_TIMEOUT, "modem-dial-timeout"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_DIAL_FAILED, "modem-dial-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_INIT_FAILED, "modem-init-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_APN_FAILED, "gsm-apn-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_REGISTRATION_NOT_SEARCHING, "gsm-registration-idle"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_REGISTRATION_DENIED, "gsm-registration-denied"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_REGISTRATION_TIMEOUT, "gsm-registration-timeout"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_REGISTRATION_FAILED, "gsm-registration-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_PIN_CHECK_FAILED, "gsm-pin-check-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_FIRMWARE_MISSING, "firmware-missing"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_REMOVED, "removed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SLEEPING, "sleeping"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_CONNECTION_REMOVED, "connection-removed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_USER_REQUESTED, "user-requested"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_CARRIER, "carrier-changed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED, "connection-assumed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SUPPLICANT_AVAILABLE, "supplicant-available"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_NOT_FOUND, "modem-not-found"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_BT_FAILED, "bluetooth-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_SIM_NOT_INSERTED, "gsm-sim-not-inserted"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_SIM_PIN_REQUIRED, "gsm-sim-pin-required"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_SIM_PUK_REQUIRED, "gsm-sim-puk-required"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_GSM_SIM_WRONG, "gsm-sim-wrong"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_INFINIBAND_MODE, "infiniband-mode"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_DEPENDENCY_FAILED, "dependency-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_BR2684_FAILED, "br2684-bridge-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_MANAGER_UNAVAILABLE, "modem-manager-unavailable"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SSID_NOT_FOUND, "ssid-not-found"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SECONDARY_CONNECTION_FAILED, "secondary-connection-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_DCB_FCOE_FAILED, "dcb-fcoe-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_TEAMD_CONTROL_FAILED, "teamd-control-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_FAILED, "modem-failed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_MODEM_AVAILABLE, "modem-available"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_SIM_PIN_INCORRECT, "sim-pin-incorrect"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_NEW_ACTIVATION, "new-activation"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_PARENT_CHANGED, "parent-changed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_PARENT_MANAGED_CHANGED, "parent-managed-changed"),
all: add OVSDB connection failure device state reason
2017-10-16 21:32:12 +02:00
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_OVSDB_FAILED, "ovsdb-failed"),
device: add a new state-reason for DAD failures
2017-11-02 14:22:10 +01:00
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_STATE_REASON_IP_ADDRESS_DUPLICATE, "ip-address-duplicate"),
device: use NM_UTILS_STRING_LOOKUP_TABLE() for reason_to_string() Showcase for the new macros NM_UTILS_STRING_LOOKUP_TABLE() and NM_UTILS_STRING_LOOKUP_TABLE_DEFINE_STATIC(). It changes behavior in case of looking up an invalid/unknown state reason. Previously it would just have returned "unknown" -- which was indistinguishable from a regular "unknown" value. Now it returns the numeric id as a string. The string is allocated with alloca(), which is desired but one should be aware of the pitfalls: - prevents the caller from being inlined - bad idea to do in a loop.
2015-12-07 14:28:09 +01:00
);
core: refactor state/reason string functions to use static tables
2014-05-20 15:13:59 -05:00
device: use NM_UTILS_STRING_LOOKUP_TABLE() for reason_to_string() Showcase for the new macros NM_UTILS_STRING_LOOKUP_TABLE() and NM_UTILS_STRING_LOOKUP_TABLE_DEFINE_STATIC(). It changes behavior in case of looking up an invalid/unknown state reason. Previously it would just have returned "unknown" -- which was indistinguishable from a regular "unknown" value. Now it returns the numeric id as a string. The string is allocated with alloca(), which is desired but one should be aware of the pitfalls: - prevents the caller from being inlined - bad idea to do in a loop.
2015-12-07 14:28:09 +01:00
#define reason_to_string(reason) \
core/trivial: rename NM_UTILS_STRING_LOOKUP_TABLE* to NM_UTILS_LOOKUP* Due to using a switch stetement, it is no longer only useful for looking up strings, and it certainly doesn't use a table anymore.
2016-01-24 14:28:31 +01:00
NM_UTILS_LOOKUP_STR (_reason_to_string, reason)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: use NMSettings directly instead of NMConnectionProvider in subclasses Instead of accessing the singleton getter nm_settings_get(), obtain the settings instance from the device instance itself via nm_device_get_settings().
2016-05-16 19:01:37 +02:00
NMSettings *
nm_device_get_settings (NMDevice *self)
{
return NM_DEVICE_GET_PRIVATE (self)->settings;
}
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
NMNetns *
nm_device_get_netns (NMDevice *self)
{
return NM_DEVICE_GET_PRIVATE (self)->netns;
}
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
NMDedupMultiIndex *
nm_device_get_multi_index (NMDevice *self)
{
return nm_netns_get_multi_idx (nm_device_get_netns (self));
}
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
NMPlatform *
nm_device_get_platform (NMDevice *self)
{
return nm_netns_get_platform (nm_device_get_netns (self));
}
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
static NMIP4Config *
_ip4_config_new (NMDevice *self)
{
return nm_ip4_config_new (nm_device_get_multi_index (self),
nm_device_get_ip_ifindex (self));
}
static NMIP6Config *
_ip6_config_new (NMDevice *self)
{
return nm_ip6_config_new (nm_device_get_multi_index (self),
nm_device_get_ip_ifindex (self));
}
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
/*****************************************************************************/
NM_UTILS_LOOKUP_STR_DEFINE_STATIC (_sys_iface_state_to_str, NMDeviceSysIfaceState,
NM_UTILS_LOOKUP_DEFAULT_NM_ASSERT ("unknown"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_SYS_IFACE_STATE_EXTERNAL, "external"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_SYS_IFACE_STATE_ASSUME, "assume"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_SYS_IFACE_STATE_MANAGED, "managed"),
NM_UTILS_LOOKUP_STR_ITEM (NM_DEVICE_SYS_IFACE_STATE_REMOVED, "removed"),
);
NMDeviceSysIfaceState
nm_device_sys_iface_state_get (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), NM_DEVICE_SYS_IFACE_STATE_EXTERNAL);
return NM_DEVICE_GET_PRIVATE (self)->sys_iface_state;
}
gboolean
nm_device_sys_iface_state_is_external (NMDevice *self)
{
return NM_IN_SET (nm_device_sys_iface_state_get (self),
NM_DEVICE_SYS_IFACE_STATE_EXTERNAL);
}
gboolean
nm_device_sys_iface_state_is_external_or_assume (NMDevice *self)
{
return NM_IN_SET (nm_device_sys_iface_state_get (self),
NM_DEVICE_SYS_IFACE_STATE_EXTERNAL,
NM_DEVICE_SYS_IFACE_STATE_ASSUME);
}
void
nm_device_sys_iface_state_set (NMDevice *self,
NMDeviceSysIfaceState sys_iface_state)
{
NMDevicePrivate *priv;
g_return_if_fail (NM_IS_DEVICE (self));
g_return_if_fail (NM_IN_SET (sys_iface_state,
NM_DEVICE_SYS_IFACE_STATE_EXTERNAL,
NM_DEVICE_SYS_IFACE_STATE_ASSUME,
NM_DEVICE_SYS_IFACE_STATE_MANAGED,
NM_DEVICE_SYS_IFACE_STATE_REMOVED));
priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->sys_iface_state != sys_iface_state) {
_LOGT (LOGD_DEVICE, "sys-iface-state: %s -> %s",
_sys_iface_state_to_str (priv->sys_iface_state),
_sys_iface_state_to_str (sys_iface_state));
priv->sys_iface_state = sys_iface_state;
}
/* this function only sets a flag, no immediate actions are initiated.
*
* If you change this, make sure that all callers are fine with such actions. */
nm_assert (priv->sys_iface_state == sys_iface_state);
}
core: add NMActivationStateFlags "layer2-ready", "ip4-ready", and "ip6-ready"
2017-09-26 14:08:27 +02:00
static void
_active_connection_set_state_flags_full (NMDevice *self,
NMActivationStateFlags flags,
NMActivationStateFlags mask)
{
NMActiveConnection *ac;
ac = NM_ACTIVE_CONNECTION (nm_device_get_act_request (self));
if (ac)
nm_active_connection_set_state_flags_full (ac, flags, mask);
}
static void
_active_connection_set_state_flags (NMDevice *self,
NMActivationStateFlags flags)
{
_active_connection_set_state_flags_full (self, flags, flags);
}
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
/*****************************************************************************/
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
void
nm_device_assume_state_get (NMDevice *self,
gboolean *out_assume_state_guess_assume,
const char **out_assume_state_connection_uuid)
{
NMDevicePrivate *priv;
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
NM_SET_OUT (out_assume_state_guess_assume, priv->assume_state_guess_assume);
NM_SET_OUT (out_assume_state_connection_uuid, priv->assume_state_connection_uuid);
}
static void
_assume_state_set (NMDevice *self,
gboolean assume_state_guess_assume,
const char *assume_state_connection_uuid)
{
NMDevicePrivate *priv;
nm_assert (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
if ( priv->assume_state_guess_assume == !!assume_state_guess_assume
&& nm_streq0 (priv->assume_state_connection_uuid, assume_state_connection_uuid))
return;
_LOGD (LOGD_DEVICE, "assume-state: set guess-assume=%c, connection=%s%s%s",
assume_state_guess_assume ? '1' : '0',
NM_PRINT_FMT_QUOTE_STRING (assume_state_connection_uuid));
priv->assume_state_guess_assume = assume_state_guess_assume;
g_free (priv->assume_state_connection_uuid);
priv->assume_state_connection_uuid = g_strdup (assume_state_connection_uuid);
}
void
nm_device_assume_state_reset (NMDevice *self)
{
g_return_if_fail (NM_IS_DEVICE (self));
_assume_state_set (self, FALSE, NULL);
}
/*****************************************************************************/
core: use default value for ipvx.dns-priority Fall back to system default value for ipvx.dns-priority when it's zero in the setting. For VPNs the default value is 50; for other connections is 100, but it depends also on the content of [connection*] sections in NetworkManager.conf.
2016-05-09 16:30:41 +02:00
static void
init_ip4_config_dns_priority (NMDevice *self, NMIP4Config *config)
{
gs_free char *value = NULL;
gint priority;
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
"ipv4.dns-priority",
self);
priority = _nm_utils_ascii_str_to_int64 (value, 10, G_MININT, G_MAXINT, 0);
nm_ip4_config_set_dns_priority (config, priority ?: NM_DNS_PRIORITY_DEFAULT_NORMAL);
}
static void
init_ip6_config_dns_priority (NMDevice *self, NMIP6Config *config)
{
gs_free char *value = NULL;
gint priority;
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
"ipv6.dns-priority",
self);
priority = _nm_utils_ascii_str_to_int64 (value, 10, G_MININT, G_MAXINT, 0);
nm_ip6_config_set_dns_priority (config, priority ?: NM_DNS_PRIORITY_DEFAULT_NORMAL);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: use default value for ipvx.dns-priority Fall back to system default value for ipvx.dns-priority when it's zero in the setting. For VPNs the default value is 50; for other connections is 100, but it depends also on the content of [connection*] sections in NetworkManager.conf.
2016-05-09 16:30:41 +02:00
device: add convenience routines for IPv4 sysctls
2017-03-16 14:51:59 +00:00
static gboolean
nm_device_ipv4_sysctl_set (NMDevice *self, const char *property, const char *value)
{
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
NMPlatform *platform = nm_device_get_platform (self);
device: add convenience routines for IPv4 sysctls
2017-03-16 14:51:59 +00:00
gs_free char *value_to_free = NULL;
const char *value_to_set;
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
char buf[NM_UTILS_SYSCTL_IP_CONF_PATH_BUFSIZE];
device: add convenience routines for IPv4 sysctls
2017-03-16 14:51:59 +00:00
device: avoid touching sysctls for devices without platform link Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to cunstruct sysctl paths and it is way less tolerant towards using something that is not an interface name in the path. It's always been incorrect to assume the ifname is a linux link name and it resulted it ugly, if benign, sysctl access attempts such as "/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc. Now it triggers an assertion failure. Let's guard all such accesses. Fixes: 32b3eb1181 Fixes: cd271d5cb1
2017-10-31 18:22:37 +01:00
if (!nm_device_get_ip_ifindex (self))
return FALSE;
device: add convenience routines for IPv4 sysctls
2017-03-16 14:51:59 +00:00
if (value) {
value_to_set = value;
} else {
/* Set to a default value when we've got a NULL @value. */
value_to_free = nm_platform_sysctl_get (platform,
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
NMP_SYSCTL_PATHID_ABSOLUTE (nm_utils_sysctl_ip_conf_path (AF_INET, buf, "default", property)));
device: add convenience routines for IPv4 sysctls
2017-03-16 14:51:59 +00:00
value_to_set = value_to_free;
}
return nm_platform_sysctl_set (platform,
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
NMP_SYSCTL_PATHID_ABSOLUTE (nm_utils_sysctl_ip_conf_path (AF_INET, buf, nm_device_get_ip_iface (self), property)),
device: add convenience routines for IPv4 sysctls
2017-03-16 14:51:59 +00:00
value_to_set);
}
static guint32
nm_device_ipv4_sysctl_get_uint32 (NMDevice *self, const char *property, guint32 fallback)
{
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
char buf[NM_UTILS_SYSCTL_IP_CONF_PATH_BUFSIZE];
core: don't use static buffer for nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). The API with static buffers looks a bit nicer. But I think they are dangerous, because we tend to pass the buffer down several layers of the stack, and it's not immediately clear, that we don't overwrite the static buffer again (which we probably did not, but it's hard to verify that there is no bug there).
2017-10-23 13:55:54 +02:00
device: avoid touching sysctls for devices without platform link Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to cunstruct sysctl paths and it is way less tolerant towards using something that is not an interface name in the path. It's always been incorrect to assume the ifname is a linux link name and it resulted it ugly, if benign, sysctl access attempts such as "/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc. Now it triggers an assertion failure. Let's guard all such accesses. Fixes: 32b3eb1181 Fixes: cd271d5cb1
2017-10-31 18:22:37 +01:00
if (!nm_device_get_ip_ifindex (self))
return fallback;
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
return nm_platform_sysctl_get_int_checked (nm_device_get_platform (self),
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
NMP_SYSCTL_PATHID_ABSOLUTE (nm_utils_sysctl_ip_conf_path (AF_INET, buf, nm_device_get_ip_iface (self), property)),
device: add convenience routines for IPv4 sysctls
2017-03-16 14:51:59 +00:00
10,
0,
G_MAXUINT32,
fallback);
}
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
gboolean
devices: abstract the handling of IPv6 sysfs properties We're about to start using a bunch more IPv6 sysfs properties, so let's start by making the code more extensible.
2014-02-21 17:04:59 -05:00
nm_device_ipv6_sysctl_set (NMDevice *self, const char *property, const char *value)
{
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
char buf[NM_UTILS_SYSCTL_IP_CONF_PATH_BUFSIZE];
core: don't use static buffer for nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). The API with static buffers looks a bit nicer. But I think they are dangerous, because we tend to pass the buffer down several layers of the stack, and it's not immediately clear, that we don't overwrite the static buffer again (which we probably did not, but it's hard to verify that there is no bug there).
2017-10-23 13:55:54 +02:00
device: avoid touching sysctls for devices without platform link Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to cunstruct sysctl paths and it is way less tolerant towards using something that is not an interface name in the path. It's always been incorrect to assume the ifname is a linux link name and it resulted it ugly, if benign, sysctl access attempts such as "/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc. Now it triggers an assertion failure. Let's guard all such accesses. Fixes: 32b3eb1181 Fixes: cd271d5cb1
2017-10-31 18:22:37 +01:00
if (!nm_device_get_ip_ifindex (self))
return FALSE;
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
return nm_platform_sysctl_set (nm_device_get_platform (self), NMP_SYSCTL_PATHID_ABSOLUTE (nm_utils_sysctl_ip_conf_path (AF_INET6, buf, nm_device_get_ip_iface (self), property)), value);
ip6: turn RA acceptance off when RAs shouldn't be used (rh #588163) Make sure we don't inadvertenly let the kernel assign an RA address when connections that don't allow RA are used.
2010-05-03 03:42:43 -07:00
}
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
static guint32
device: fix sysctl getter for MTU using guint32 type The only caller wants to read the MTU, which is more type guint32 then gint32.
2017-01-14 12:51:01 +01:00
nm_device_ipv6_sysctl_get_uint32 (NMDevice *self, const char *property, guint32 fallback)
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
{
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
char buf[NM_UTILS_SYSCTL_IP_CONF_PATH_BUFSIZE];
core: don't use static buffer for nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). The API with static buffers looks a bit nicer. But I think they are dangerous, because we tend to pass the buffer down several layers of the stack, and it's not immediately clear, that we don't overwrite the static buffer again (which we probably did not, but it's hard to verify that there is no bug there).
2017-10-23 13:55:54 +02:00
device: avoid touching sysctls for devices without platform link Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to cunstruct sysctl paths and it is way less tolerant towards using something that is not an interface name in the path. It's always been incorrect to assume the ifname is a linux link name and it resulted it ugly, if benign, sysctl access attempts such as "/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc. Now it triggers an assertion failure. Let's guard all such accesses. Fixes: 32b3eb1181 Fixes: cd271d5cb1
2017-10-31 18:22:37 +01:00
if (!nm_device_get_ip_ifindex (self))
return fallback;
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
return nm_platform_sysctl_get_int_checked (nm_device_get_platform (self),
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
NMP_SYSCTL_PATHID_ABSOLUTE (nm_utils_sysctl_ip_conf_path (AF_INET6, buf, nm_device_get_ip_iface (self), property)),
device: fix sysctl getter for MTU using guint32 type The only caller wants to read the MTU, which is more type guint32 then gint32.
2017-01-14 12:51:01 +01:00
10,
0,
G_MAXUINT32,
fallback);
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
}
device: expose nm_device_has_capability() function
2015-04-17 15:19:48 +02:00
gboolean
nm_device_has_capability (NMDevice *self, NMDeviceCapabilities caps)
core: add driver-version, firmware-version properties to NMDevice (bgo #636124) The info is extracted via SIOCETHTOOL ioctl() syscall using ETHTOOL_GDRVINFO. This works for most drivers but not all, e.g. for modems. We may figure out how to get the info for specific devices, and enhance the solution by implementing specific functions for particular device types later.
2012-06-01 16:48:57 +02:00
{
device: use NMDeviceCapabilities enum for device capabilities
2015-04-17 15:15:38 +02:00
return NM_FLAGS_ANY (NM_DEVICE_GET_PRIVATE (self)->capabilities, caps);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: add driver-version, firmware-version properties to NMDevice (bgo #636124) The info is extracted via SIOCETHTOOL ioctl() syscall using ETHTOOL_GDRVINFO. This works for most drivers but not all, e.g. for modems. We may figure out how to get the info for specific devices, and enhance the solution by implementing specific functions for particular device types later.
2012-06-01 16:48:57 +02:00
device: add function to change device capabilites
2016-05-09 18:16:45 +02:00
static void
_add_capabilities (NMDevice *self, NMDeviceCapabilities capabilities)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if (!NM_FLAGS_ALL (priv->capabilities, capabilities)) {
priv->capabilities |= capabilities;
_notify (self, PROP_CAPABILITIES);
}
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
device: share implementation of hw_is_up, hw_bring_up and hw_take_down
2013-01-22 16:43:15 +01:00
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
static const char *
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
_get_stable_id (NMDevice *self,
NMConnection *connection,
NMUtilsStableType *out_stable_type)
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
{
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
NMDevicePrivate *priv;
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
nm_assert (NM_IS_DEVICE (self));
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
nm_assert (NM_IS_CONNECTION (connection));
nm_assert (out_stable_type);
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
priv = NM_DEVICE_GET_PRIVATE (self);
/* we cache the generated stable ID for the time of an activation.
*
* The reason is, that we don't want the stable-id to change as long
* as the device is active.
*
* Especially with ${RANDOM} stable-id we want to generate *one* configuration
* for each activation. */
if (G_UNLIKELY (!priv->current_stable_id)) {
gs_free char *default_id = NULL;
gs_free char *generated = NULL;
NMUtilsStableType stable_type;
NMSettingConnection *s_con;
const char *stable_id;
const char *uuid;
s_con = nm_connection_get_setting_connection (connection);
stable_id = nm_setting_connection_get_stable_id (s_con);
if (!stable_id) {
default_id = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
"connection.stable-id",
self);
stable_id = default_id;
}
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
uuid = nm_connection_get_uuid (connection);
stable_type = nm_utils_stable_id_parse (stable_id,
uuid,
NULL,
&generated);
/* current_stable_id_type is a bitfield! */
priv->current_stable_id_type = stable_type;
device: fix invalid assertion Fixes: f0d40525dfb079820e5dce48360ef6a9a540064a
2017-01-09 20:22:06 +01:00
nm_assert (stable_type <= (NMUtilsStableType) 0x3);
nm_assert (stable_type + (NMUtilsStableType) 1 > (NMUtilsStableType) 0);
nm_assert (priv->current_stable_id_type == stable_type);
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
if (stable_type == NM_UTILS_STABLE_TYPE_UUID)
priv->current_stable_id = g_strdup (uuid);
else if (stable_type == NM_UTILS_STABLE_TYPE_STABLE_ID)
priv->current_stable_id = g_strdup (stable_id);
else if (stable_type == NM_UTILS_STABLE_TYPE_GENERATED)
priv->current_stable_id = nm_str_realloc (nm_utils_stable_id_generated_complete (generated));
else {
nm_assert (stable_type == NM_UTILS_STABLE_TYPE_RANDOM);
priv->current_stable_id = nm_str_realloc (nm_utils_stable_id_random ());
}
_LOGT (LOGD_DEVICE,
"stable-id: type=%d, \"%s\""
"%s%s%s",
(int) priv->current_stable_id_type,
priv->current_stable_id,
NM_PRINT_FMT_QUOTED (stable_type == NM_UTILS_STABLE_TYPE_GENERATED, " from \"", generated, "\"", ""));
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
}
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
*out_stable_type = priv->current_stable_id_type;
return priv->current_stable_id;
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
NM_UTILS_LOOKUP_STR_DEFINE_STATIC (_ip_state_to_string, IpState,
NM_UTILS_LOOKUP_DEFAULT_WARN ("unknown"),
NM_UTILS_LOOKUP_STR_ITEM (IP_NONE, "none"),
NM_UTILS_LOOKUP_STR_ITEM (IP_WAIT, "wait"),
NM_UTILS_LOOKUP_STR_ITEM (IP_CONF, "conf"),
NM_UTILS_LOOKUP_STR_ITEM (IP_DONE, "done"),
NM_UTILS_LOOKUP_STR_ITEM (IP_FAIL, "fail"),
);
static void
_set_ip_state (NMDevice *self, int addr_family, IpState new_state)
{
IpState *p;
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
nm_assert_addr_family (addr_family);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
p = (addr_family == AF_INET)
? &priv->ip4_state_
: &priv->ip6_state_;
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
if (*p != new_state) {
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
_LOGT (LOGD_DEVICE, "ip%c-state: set to %d (%s)",
nm_utils_addr_family_to_char (addr_family),
(int) new_state,
_ip_state_to_string (new_state));
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
*p = new_state;
core: add NMActivationStateFlags "layer2-ready", "ip4-ready", and "ip6-ready"
2017-09-26 14:08:27 +02:00
if (new_state == IP_DONE) {
/* we only set the IPx_READY flag once we reach IP_DONE state. We don't
* ever clear it, even if we later enter IP_FAIL state.
*
* This is not documented/guaranteed behavior, but seems to make sense for now. */
_active_connection_set_state_flags (self,
addr_family == AF_INET
? NM_ACTIVATION_STATE_FLAG_IP4_READY
: NM_ACTIVATION_STATE_FLAG_IP6_READY);
}
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
}
}
/*****************************************************************************/
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
const char *
nm_device_get_udi (NMDevice *self)
{
g_return_val_if_fail (self != NULL, NULL);
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
return NM_DEVICE_GET_PRIVATE (self)->udi;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
const char *
nm_device_get_iface (NMDevice *self)
{
device: use NULL instead of 0 in g_return_val_if_fail() for pointer
2015-07-08 16:49:19 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
return NM_DEVICE_GET_PRIVATE (self)->iface;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
gboolean
ppp: rename the interface only when necessary Previously when the interface created by pppd was already the one we expected, we would rename it to itself and remove the device from the manager. Don't do it. Fixes: 6c3195931e94cab70208ce97f3b834f5d9f5ff62
2017-09-08 14:09:51 +02:00
nm_device_take_over_link (NMDevice *self, const char *ifname, gboolean *renamed)
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
const NMPlatformLink *plink;
NMPlatform *platform;
ppp: rename the interface only when necessary Previously when the interface created by pppd was already the one we expected, we would rename it to itself and remove the device from the manager. Don't do it. Fixes: 6c3195931e94cab70208ce97f3b834f5d9f5ff62
2017-09-08 14:09:51 +02:00
gboolean up, success = TRUE;
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
int ifindex;
g_return_val_if_fail (priv->ifindex <= 0, FALSE);
ppp: rename the interface only when necessary Previously when the interface created by pppd was already the one we expected, we would rename it to itself and remove the device from the manager. Don't do it. Fixes: 6c3195931e94cab70208ce97f3b834f5d9f5ff62
2017-09-08 14:09:51 +02:00
g_return_val_if_fail (ifname, FALSE);
NM_SET_OUT (renamed, FALSE);
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
platform = nm_device_get_platform (self);
plink = nm_platform_link_get_by_ifname (platform, ifname);
if (!plink)
return FALSE;
ifindex = plink->ifindex;
ppp: rename the interface only when necessary Previously when the interface created by pppd was already the one we expected, we would rename it to itself and remove the device from the manager. Don't do it. Fixes: 6c3195931e94cab70208ce97f3b834f5d9f5ff62
2017-09-08 14:09:51 +02:00
if (!nm_streq (ifname, nm_device_get_iface (self))) {
up = NM_FLAGS_HAS (plink->n_ifi_flags, IFF_UP);
/* Rename the link to the device ifname */
if (up)
nm_platform_link_set_down (platform, ifindex);
success = nm_platform_link_set_name (platform, ifindex, nm_device_get_iface (self));
if (up)
nm_platform_link_set_up (platform, ifindex, NULL);
NM_SET_OUT (renamed, success);
}
core: implement activation of PPP devices Add code to NMPppDevice to activate new-style PPPoE connections. This is a bit tricky because we can't create the link as usual in create_and_realize(). Instead, we create a device without ifindex and start pppd in stage2; when pppd reports a new configuration, we rename the platform link to the correct name and set the ifindex into the device. This mechanism is inherently racy, but there is no way to tell pppd to create an arbitrary interface name.
2017-07-03 16:24:59 +02:00
if (success) {
priv->ifindex = ifindex;
_notify (self, PROP_IFINDEX);
}
return success;
}
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
int
nm_device_get_ifindex (NMDevice *self)
{
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
g_return_val_if_fail (NM_IS_DEVICE (self), 0);
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
return NM_DEVICE_GET_PRIVATE (self)->ifindex;
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
/**
* nm_device_is_software:
* @self: the #NMDevice
*
* Indicates if the device is a software-based virtual device without
* backing hardware, which can be added and removed programmatically.
*
* Returns: %TRUE if the device is a software-based device
*/
core: implement nm_device_is_software() Cache the result of nm_platform_link_is_software() in NMDevice. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-08-22 19:15:05 +02:00
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_is_software (NMDevice *self)
core: implement nm_device_is_software() Cache the result of nm_platform_link_is_software() in NMDevice. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-08-22 19:15:05 +02:00
{
core: earlier software capability detection We need to know whether we can create interfaces of any given NMDevice subclass or not. So don't rely on just the NMPlatformLink for that information, because we won't have a platform link for software devices before we create them.
2014-09-24 17:46:15 -05:00
return NM_FLAGS_HAS (NM_DEVICE_GET_PRIVATE (self)->capabilities, NM_DEVICE_CAP_IS_SOFTWARE);
core: implement nm_device_is_software() Cache the result of nm_platform_link_is_software() in NMDevice. Acked-by: Dan Winship <danw@gnome.org> Acked-by: Thomas Haller <thaller@redhat.com>
2013-08-22 19:15:05 +02:00
}
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
/**
* nm_device_is_real:
* @self: the #NMDevice
*
* Returns: %TRUE if the device exists, %FALSE if the device is a placeholder
*/
gboolean
nm_device_is_real (NMDevice *self)
{
device: only set NMDevice as "real" at the end of nm_device_realize_finish() Only set the device as "real" at the end of nm_device_realize_finish(), not already during nm_device_realize_start()/realize_start_setup().
2016-01-12 10:38:16 +01:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
return NM_DEVICE_GET_PRIVATE (self)->real;
}
2008-03-07 Dan Williams <dcbw@redhat.com> First pass of multiple active device support. Expect bugs. * src/nm-ip4-config.c src/nm-ip4-config.h - (nm_ip4_config_get_secondary, nm_ip4_config_set_secondary): remove; there are better ways to do this in the named manager * src/nm-device.c src/nm-device.h - (nm_device_can_activate): return whether the device can activate a connection right now; taking into account things like carrier state and rfkill state - (nm_device_get_best_auto_connection): renamed from nm_device_get_best_connection - (real_act_stage4_get_ip4_config): MTU stuff is now handled in the device subclasses themselves, so that each device can override the MTU from it's NMSetting subclass if needed - (nm_device_set_ip4_config): set MTU when setting up routes and stuff in NetworkManagerSystem.c, not here * src/named-manager/nm-named-manager.c src/named-manager/nm-named-manager.h - (nm_named_manager_name_owner_changed, nm_named_manager_dbus_connection_changed): fix for changes to rewrite_resolv_conf() - (compute_nameservers): don't need the NMNamedManager at all, remove from parameter list - (merge_one_ip4_config): new function; merge ip4 configs together - (rewrite_resolv_conf): write out resolv.conf from all the stored ip4 configs; the VPN config takes precedence, then the best device config, then the rest of the configs - (get_domain_for_config): take the NMNamedManager as an argument to check whether the config is the VPN config - (add_ip4_config_to_named): fixups for removal of the 'secondary' attribute from ip4 configs - (add_all_ip4_configs_to_named): add all the configs in priority order - (remove_ip4_config_from_named): fix for changes to get_domain_for_config() - (nm_named_manager_add_ip4_config): assign the config to the right slot based on its type; callers must pass in the type now - (get_last_default_domain): remove, unused - (nm_named_manager_remove_ip4_config): handle config slots correctly * src/nm-device-802-11-wireless.c - (real_can_activate): new function - (real_get_best_auto_connection): renamed from real_get_best_connection - (real_act_stage4_get_ip4_config): handle MTU override * src/nm-device-802-3-ethernet.c - (real_can_activate): new function - (real_get_best_auto_connection): renamed from real_get_best_connection - (real_act_stage4_get_ip4_config): new function; handle MTU override * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_ip4_config_get): don't need to set the 'secondary' attribute on the ip4 config * src/NetworkManagerPolicy.c - (nm_policy_auto_get_best_device): remove - (nm_policy_device_change_check): remove - (update_default_route): new function; set the default route via the specified device - (get_device_priority): new function; return the priority number of a device type WRT which one should have the default route. Order is (highest to lowest) wired, wireless, GSM, CDMA. - (update_routing_and_dns): new function; determine which device should have the default route, then update the routing table and DNS - (maybe_auto_activate_device): new function; if a device is now available for activation, find out what connection it would like to activate and do it - (schedule_activate_check): new function; if a device can be activated now, schedule the activation. Each device may have only one pending activation at a given time. - (device_state_changed): if activation was canceled, try again, possibly with another connection; if the device was activated, update routing and DNS; if the device was deactivated, try again with another connection - (device_carrier_changed): if there is no carrier, deactivate the device; otherwise schedule an activation check for the device - (wireless_networks_changed): schedule an activation check for the device - (device_added): keep track of the signal handler IDs so they can be removed when the device goes away - (device_removed): remove any signal handlers that might be attached to the device; update routing and DNS - (schedule_activate_all): new function - (connections_added, connection_added, connection_updated): when connections change, schedule all devices for an activation check - (connection_removed): when a device is deactivated because its connection was removed, schedule another activation check for it - (nm_policy_destroy): destroy pending activations and disconnect all device signal handlers * src/nm-manager.c - (nm_manager_activate_device): if the device was already actived, deactivate it - (deactivate_old_device): remove - (connection_added_default_handler, impl_manager_activate_device): don't deactivate other devices when activating this one * src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerArch.c src/backends/NetworkManagerSuSE.c src/backends/NetworkManagerDebian.c - (nm_system_get_mtu): remove; MTU should be provided through the distro's system settings service plugin instead - (nm_system_device_add_default_route_via_device): remove - (nm_system_device_add_default_route_via_device_with_iface): remove - (nm_system_device_replace_default_route): new function; call generic implementation * src/backends/NetworkManagerGeneric.c src/backends/NetworkManagerGeneric.h - (nm_generic_device_add_default_route_via_device, nm_generic_device_add_default_route_via_device_with_iface): remove - (nm_generic_device_replace_default_route): replace the default route with the given route via some gateway * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_from_ip4_config): let the policy handle updates to routing and DNS; but set the MTU here - (nm_system_vpn_device_set_from_ip4_config): set the route with the ip_iface of the active device; use the standard MTU setting function - (nm_system_set_mtu): remove - (nm_system_device_set_mtu): consolidate MTU setting code in one place git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3391 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-07 19:41:32 +00:00
const char *
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
nm_device_get_ip_iface (NMDevice *self)
{
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
NMDevicePrivate *priv;
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
g_return_val_if_fail (self != NULL, NULL);
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
priv = NM_DEVICE_GET_PRIVATE (self);
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
/* If it's not set, default to iface */
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
return priv->ip_iface ? priv->ip_iface : priv->iface;
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
}
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
int
nm_device_get_ip_ifindex (NMDevice *self)
{
NMDevicePrivate *priv;
g_return_val_if_fail (self != NULL, 0);
priv = NM_DEVICE_GET_PRIVATE (self);
device: trivial: fix a copy/paste error in comment
2015-05-27 11:20:31 +02:00
/* If it's not set, default to ifindex */
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
return priv->ip_iface ? priv->ip_ifindex : priv->ifindex;
}
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
device/wwan: indicate whether IP iface/ifindex changed and simplify WwAN code Replace some code in the WWAN device class that checks for a changed interface name with code that uses the new return value from nm_device_set_ip_iface(), which now checks whether the ip_ifindex changed too. https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00010.html
2017-01-11 19:35:09 -06:00
/**
* nm_device_set_ip_iface:
* @self: the #NMDevice
* @iface: the new IP interface name
*
* Updates the IP interface name and possibly the ifindex.
*
* Returns: %TRUE if the anything (name or ifindex) changed, %FALSE if nothing
* changed.
*/
gboolean
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
nm_device_set_ip_iface (NMDevice *self, const char *iface)
{
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
NMDevicePrivate *priv;
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
int ifindex;
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
device/wwan: indicate whether IP iface/ifindex changed and simplify WwAN code Replace some code in the WWAN device class that checks for a changed interface name with code that uses the new return value from nm_device_set_ip_iface(), which now checks whether the ip_ifindex changed too. https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00010.html
2017-01-11 19:35:09 -06:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
priv = NM_DEVICE_GET_PRIVATE (self);
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
if (nm_streq0 (iface, priv->ip_iface)) {
if (!iface)
device/wwan: indicate whether IP iface/ifindex changed and simplify WwAN code Replace some code in the WWAN device class that checks for a changed interface name with code that uses the new return value from nm_device_set_ip_iface(), which now checks whether the ip_ifindex changed too. https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00010.html
2017-01-11 19:35:09 -06:00
return FALSE;
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
ifindex = nm_platform_if_nametoindex (nm_device_get_platform (self), iface);
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
if ( ifindex <= 0
|| priv->ip_ifindex == ifindex)
device/wwan: indicate whether IP iface/ifindex changed and simplify WwAN code Replace some code in the WWAN device class that checks for a changed interface name with code that uses the new return value from nm_device_set_ip_iface(), which now checks whether the ip_ifindex changed too. https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00010.html
2017-01-11 19:35:09 -06:00
return FALSE;
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
priv->ip_ifindex = ifindex;
_LOGD (LOGD_DEVICE, "ip-ifname: update ifindex for ifname '%s': %d", iface, priv->ip_ifindex);
} else {
g_free (priv->ip_iface);
priv->ip_iface = g_strdup (iface);
if (iface) {
/* The @iface name is not in sync with the platform cache.
* So, there is no point asking the platform cache to resolve
* the ifindex. Instead, we can only hope that the interface
* with this name still exists and we resolve the ifindex
* anew.
*/
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
priv->ip_ifindex = nm_platform_if_nametoindex (nm_device_get_platform (self), iface);
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
if (priv->ip_ifindex > 0)
_LOGD (LOGD_DEVICE, "ip-ifname: set ifname '%s', ifindex %d", iface, priv->ip_ifindex);
else
_LOGW (LOGD_DEVICE, "ip-ifname: set ifname '%s', unknown ifindex", iface);
core: don't up devices during IP configuration stages Assumed connections shouldn't require touching the device, and the device should was already set IFF_UP during stage2 (which is skipped for assumed connections). Instead, what the code was really trying to do, was to ensure tha the IP interface the device was going to use was up. The only cases where the IP interface might *not* be up after stage2 is where the IP interface is different than the device's interface, like for Bluetooth, ADSL, WWAN, and PPPoE. Move the call to nm_platform_link_set_up() into nm_device_set_ip_iface() which all those device types will call. Thus, only the device types that really need to up their IP interface will do so, but other devices (including when activating assumed connections) that don't need to do this, won't do it.
2013-11-08 10:58:35 -06:00
} else {
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
priv->ip_ifindex = 0;
_LOGD (LOGD_DEVICE, "ip-ifname: clear ifname");
core: use ifindex instead of interface name in a lot of places Where we can do so, let's use ifindex since that's actually unique and doesn't change when the interface name changes. We already use ifindex in a bunch of places, and netlink *only* uses ifindex, so this will make it easier later when we move over to ifindexes fully.
2010-04-21 14:58:25 -07:00
}
}
core: expose device's IP interface when activated Lets apps find out what the actual kernel interface name is for the device so they can do fun stuff with it.
2010-06-10 10:16:39 -07:00
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
if (priv->ip_ifindex > 0) {
platform: refactor detecting kernel support We are going to add another parameter to check. Instead of adding multiple virtual functions, add a NMPlatformKernelSupportFlags flags enum.
2017-10-10 18:20:05 +02:00
if (nm_platform_check_kernel_support (nm_device_get_platform (self),
NM_PLATFORM_KERNEL_SUPPORT_USER_IPV6LL))
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_set_user_ipv6ll_enabled (nm_device_get_platform (self), priv->ip_ifindex, TRUE);
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_is_up (nm_device_get_platform (self), priv->ip_ifindex))
nm_platform_link_set_up (nm_device_get_platform (self), priv->ip_ifindex, NULL);
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
}
device: properly handle MTU for devices with @iface != @ip_iface When the device has an IP interface different from the main one, we previously took the MTU saved in priv->mtu (which is the MTU initially set on the underlying interface) and applied it to the IP interface. This is wrong as it forces the two MTUs to be equal and breaks connectivity for devices with encapsulation (as PPP). Instead, track the two MTUs in different variables. https://bugzilla.redhat.com/show_bug.cgi?id=1385198
2016-10-19 15:55:01 +02:00
devices: abstract the handling of IPv6 sysfs properties We're about to start using a bunch more IPv6 sysfs properties, so let's start by making the code more extensible.
2014-02-21 17:04:59 -05:00
/* We don't care about any saved values from the old iface */
g_hash_table_remove_all (priv->ip6_saved_properties);
devices: clean up accept_ra/use_tempaddr handling update_accept_ra_path() and update_ip6_privacy_save() were freeing their path variables if they failed to read the existing values, but if this ever actually happened it would cause problems later since other code assumed that the variables were always set. Use "priv->ip6_accept_ra_save = -1", etc, instead to indicate that the value couldn't be read (and so shouldn't be restored later). Merge the accept_ra and use_tempaddr code save/restore code together, since they're always called together. Fix the accept_ra-restoring code to correctly handle an original value of "2". Call update_ip6_properties_paths() from nm_device_set_ip_iface() rather than act_stage3_ip6_config_start(), since set_ip_iface() is when the paths actually change. Also, split the default-value-saving code out into a separate function, since we only care about doing that at construct time; if the IP6 property paths change later (because iface != ip_iface), then we don't need to save and restore the values on the ip_iface, since the interface will go away when we're done with it. https://bugzilla.gnome.org/show_bug.cgi?id=700414
2013-10-24 13:55:06 -04:00
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
_notify (self, PROP_IP_IFACE);
device/wwan: indicate whether IP iface/ifindex changed and simplify WwAN code Replace some code in the WWAN device class that checks for a changed interface name with code that uses the new return value from nm_device_set_ip_iface(), which now checks whether the ip_ifindex changed too. https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00010.html
2017-01-11 19:35:09 -06:00
return TRUE;
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
}
static gboolean
_ip_iface_update (NMDevice *self, const char *ip_iface)
{
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
g_return_val_if_fail (priv->ip_iface, FALSE);
g_return_val_if_fail (priv->ip_ifindex > 0, FALSE);
g_return_val_if_fail (ip_iface, FALSE);
if (!ip_iface[0])
return FALSE;
if (nm_streq (priv->ip_iface, ip_iface))
return FALSE;
_LOGI (LOGD_DEVICE, "ip-ifname: interface index %d renamed ip_iface (%d) from '%s' to '%s'",
priv->ifindex, priv->ip_ifindex,
priv->ip_iface, ip_iface);
g_free (priv->ip_iface);
priv->ip_iface = g_strdup (ip_iface);
_notify (self, PROP_IP_IFACE);
return TRUE;
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
}
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
/*****************************************************************************/
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
int
nm_device_parent_get_ifindex (NMDevice *self)
{
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), 0);
priv = NM_DEVICE_GET_PRIVATE (self);
return priv->parent_ifindex;
}
NMDevice *
nm_device_parent_get_device (NMDevice *self)
{
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
priv = NM_DEVICE_GET_PRIVATE (self);
return priv->parent_device;
}
static void
parent_changed_notify (NMDevice *self,
int old_ifindex,
NMDevice *old_parent,
int new_ifindex,
NMDevice *new_parent)
{
/* empty handler to allow subclasses to always chain up the virtual function. */
}
static gboolean
_parent_set_ifindex (NMDevice *self,
int parent_ifindex,
gboolean force_check)
{
NMDevicePrivate *priv;
NMDevice *parent_device;
gboolean changed = FALSE;
int old_ifindex;
NMDevice *old_device;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
if (parent_ifindex <= 0)
parent_ifindex = 0;
old_ifindex = priv->parent_ifindex;
old_device = priv->parent_device;
if (priv->parent_ifindex == parent_ifindex) {
if (parent_ifindex > 0) {
if ( !force_check
&& priv->parent_device
&& nm_device_get_ifindex (priv->parent_device) == parent_ifindex)
return FALSE;
} else {
if (!priv->parent_device)
return FALSE;
}
} else {
priv->parent_ifindex = parent_ifindex;
changed = TRUE;
}
if (parent_ifindex > 0) {
parent_device = nm_manager_get_device_by_ifindex (nm_manager_get (), parent_ifindex);
if (parent_device == self)
parent_device = NULL;
} else
parent_device = NULL;
if (parent_device != priv->parent_device) {
priv->parent_device = parent_device;
changed = TRUE;
}
if (changed) {
if (priv->parent_ifindex <= 0)
_LOGD (LOGD_DEVICE, "parent: clear");
else if (!priv->parent_device)
_LOGD (LOGD_DEVICE, "parent: ifindex %d, no device", priv->parent_ifindex);
else {
_LOGD (LOGD_DEVICE, "parent: ifindex %d, device %p, %s", priv->parent_ifindex,
priv->parent_device, nm_device_get_iface (priv->parent_device));
}
NM_DEVICE_GET_CLASS (self)->parent_changed_notify (self, old_ifindex, old_device, priv->parent_ifindex, priv->parent_device);
_notify (self, PROP_PARENT);
}
return changed;
}
void
nm_device_parent_set_ifindex (NMDevice *self,
int parent_ifindex)
{
_parent_set_ifindex (self, parent_ifindex, FALSE);
}
gboolean
nm_device_parent_notify_changed (NMDevice *self,
NMDevice *change_candidate,
gboolean device_removed)
{
NMDevicePrivate *priv;
nm_assert (NM_IS_DEVICE (self));
nm_assert (NM_IS_DEVICE (change_candidate));
priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->parent_ifindex > 0) {
if ( priv->parent_device == change_candidate
|| priv->parent_ifindex == nm_device_get_ifindex (change_candidate))
return _parent_set_ifindex (self, priv->parent_ifindex, device_removed);
}
return FALSE;
}
/*****************************************************************************/
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
static void
_stats_update_counters (NMDevice *self,
guint64 tx_bytes,
guint64 rx_bytes)
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
{
NMDevicePrivate *priv;
priv = NM_DEVICE_GET_PRIVATE (self);
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
if (priv->stats.tx_bytes != tx_bytes) {
priv->stats.tx_bytes = tx_bytes;
_notify (self, PROP_TX_BYTES);
}
if (priv->stats.rx_bytes != rx_bytes) {
priv->stats.rx_bytes = rx_bytes;
_notify (self, PROP_RX_BYTES);
}
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
}
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
static void
device: always expose device statistics information Instead of updating the device-statistic counters only periodically as we refresh the link, update them on every link-changed event from platform. That means, also for devices that have RefreshRateMs at zero, the values will be updated at random times when the link information changes. The difference is, that previously the counters would be zero unless RefreshRateMs was set. Now, they have some (probably stale) values which however are not guaranteed to be kept up-to-date. Also, now we refresh more often then promised by RefreshRateMs. But the API technically doesn't specify that, so if we find there is a problem with this, we may revert it later.
2016-08-16 15:55:04 +02:00
_stats_update_counters_from_pllink (NMDevice *self, const NMPlatformLink *pllink)
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
{
device: always expose device statistics information Instead of updating the device-statistic counters only periodically as we refresh the link, update them on every link-changed event from platform. That means, also for devices that have RefreshRateMs at zero, the values will be updated at random times when the link information changes. The difference is, that previously the counters would be zero unless RefreshRateMs was set. Now, they have some (probably stale) values which however are not guaranteed to be kept up-to-date. Also, now we refresh more often then promised by RefreshRateMs. But the API technically doesn't specify that, so if we find there is a problem with this, we may revert it later.
2016-08-16 15:55:04 +02:00
_stats_update_counters (self, pllink->tx_bytes, pllink->rx_bytes);
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
}
static gboolean
_stats_timeout_cb (gpointer user_data)
{
NMDevice *self = user_data;
device: always expose device statistics information Instead of updating the device-statistic counters only periodically as we refresh the link, update them on every link-changed event from platform. That means, also for devices that have RefreshRateMs at zero, the values will be updated at random times when the link information changes. The difference is, that previously the counters would be zero unless RefreshRateMs was set. Now, they have some (probably stale) values which however are not guaranteed to be kept up-to-date. Also, now we refresh more often then promised by RefreshRateMs. But the API technically doesn't specify that, so if we find there is a problem with this, we may revert it later.
2016-08-16 15:55:04 +02:00
int ifindex;
ifindex = nm_device_get_ip_ifindex (self);
_LOGT (LOGD_DEVICE, "stats: refresh %d", ifindex);
if (ifindex > 0)
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_refresh (nm_device_get_platform (self), ifindex);
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
return G_SOURCE_CONTINUE;
}
static guint
_stats_refresh_rate_real (guint refresh_rate_ms)
{
const guint STATS_REFRESH_RATE_MS_MIN = 200;
if (refresh_rate_ms == 0)
return 0;
if (refresh_rate_ms < STATS_REFRESH_RATE_MS_MIN) {
/* you cannot set the refresh-rate arbitrarly small. E.g.
* setting to 1ms is just killing. Have a lowest number. */
return STATS_REFRESH_RATE_MS_MIN;
}
return refresh_rate_ms;
}
static void
_stats_set_refresh_rate (NMDevice *self, guint refresh_rate_ms)
{
NMDevicePrivate *priv;
device: always expose device statistics information Instead of updating the device-statistic counters only periodically as we refresh the link, update them on every link-changed event from platform. That means, also for devices that have RefreshRateMs at zero, the values will be updated at random times when the link information changes. The difference is, that previously the counters would be zero unless RefreshRateMs was set. Now, they have some (probably stale) values which however are not guaranteed to be kept up-to-date. Also, now we refresh more often then promised by RefreshRateMs. But the API technically doesn't specify that, so if we find there is a problem with this, we may revert it later.
2016-08-16 15:55:04 +02:00
int ifindex;
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
guint old_rate;
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
if (priv->stats.refresh_rate_ms == refresh_rate_ms)
return;
old_rate = priv->stats.refresh_rate_ms;
priv->stats.refresh_rate_ms = refresh_rate_ms;
_notify (self, PROP_REFRESH_RATE_MS);
_LOGD (LOGD_DEVICE, "stats: set refresh to %u ms", priv->stats.refresh_rate_ms);
if (!nm_device_is_real (self))
return;
refresh_rate_ms = _stats_refresh_rate_real (refresh_rate_ms);
if (_stats_refresh_rate_real (old_rate) == refresh_rate_ms)
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
return;
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
nm_clear_g_source (&priv->stats.timeout_id);
device: always expose device statistics information Instead of updating the device-statistic counters only periodically as we refresh the link, update them on every link-changed event from platform. That means, also for devices that have RefreshRateMs at zero, the values will be updated at random times when the link information changes. The difference is, that previously the counters would be zero unless RefreshRateMs was set. Now, they have some (probably stale) values which however are not guaranteed to be kept up-to-date. Also, now we refresh more often then promised by RefreshRateMs. But the API technically doesn't specify that, so if we find there is a problem with this, we may revert it later.
2016-08-16 15:55:04 +02:00
if (!refresh_rate_ms)
return;
/* trigger an inital refresh of the data whenever the refresh-rate changes.
* As we process the result in an idle handler with device_link_changed(),
* we don't get the result right away. */
ifindex = nm_device_get_ip_ifindex (self);
if (ifindex > 0)
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_refresh (nm_device_get_platform (self), ifindex);
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
priv->stats.timeout_id = g_timeout_add (refresh_rate_ms, _stats_timeout_cb, self);
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
}
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
/*****************************************************************************/
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
static gboolean
get_ip_iface_identifier (NMDevice *self, NMUtilsIPv6IfaceId *out_iid)
{
core: use dev_id when calculating the interface IPv6 IID (rh #1101809) Some device types (s390 OSA and ipvlan) can use the same link-layer address for multiple virtual interfaces, and the kernel used the dev_id property to differentiate these devices when constructing the IID. NM should do this too to prevent IID clashes. https://bugzilla.redhat.com/show_bug.cgi?id=1101809
2015-03-24 12:46:18 -05:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: lookup platform data only once in get_ip_iface_identifier() No need to perform multiple cache lookups.
2016-05-09 17:19:30 +02:00
const NMPlatformLink *pllink;
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
int ifindex;
gboolean success;
/* If we get here, we *must* have a kernel netdev, which implies an ifindex */
ifindex = nm_device_get_ip_ifindex (self);
device: accept failure to lookup link in get_ip_iface_identifier() An assertion seems a bit harsh, especially, because the platform cache cannot be always in sync with the device state.
2016-05-09 17:21:41 +02:00
g_return_val_if_fail (ifindex > 0, FALSE);
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
pllink = nm_platform_link_get (nm_device_get_platform (self), ifindex);
device: accept failure to lookup link in get_ip_iface_identifier() An assertion seems a bit harsh, especially, because the platform cache cannot be always in sync with the device state.
2016-05-09 17:21:41 +02:00
if ( !pllink
|| NM_IN_SET (pllink->type, NM_LINK_TYPE_NONE, NM_LINK_TYPE_UNKNOWN))
return FALSE;
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
device: lookup platform data only once in get_ip_iface_identifier() No need to perform multiple cache lookups.
2016-05-09 17:19:30 +02:00
if (pllink->addr.len <= 0)
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
return FALSE;
device: lookup platform data only once in get_ip_iface_identifier() No need to perform multiple cache lookups.
2016-05-09 17:19:30 +02:00
if (pllink->addr.len > NM_UTILS_HWADDR_LEN_MAX)
g_return_val_if_reached (FALSE);
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
device: lookup platform data only once in get_ip_iface_identifier() No need to perform multiple cache lookups.
2016-05-09 17:19:30 +02:00
success = nm_utils_get_ipv6_interface_identifier (pllink->type,
pllink->addr.data,
pllink->addr.len,
core: use dev_id when calculating the interface IPv6 IID (rh #1101809) Some device types (s390 OSA and ipvlan) can use the same link-layer address for multiple virtual interfaces, and the kernel used the dev_id property to differentiate these devices when constructing the IID. NM should do this too to prevent IID clashes. https://bugzilla.redhat.com/show_bug.cgi?id=1101809
2015-03-24 12:46:18 -05:00
priv->dev_id,
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
out_iid);
if (!success) {
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGW (LOGD_PLATFORM, "failed to generate interface identifier "
device: lookup platform data only once in get_ip_iface_identifier() No need to perform multiple cache lookups.
2016-05-09 17:19:30 +02:00
"for link type %u hwaddr_len %u", pllink->type, (unsigned) pllink->addr.len);
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
}
return success;
}
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
/**
* nm_device_get_ip_iface_identifier:
* @self: an #NMDevice
* @iid: where to place the interface identifier
* @ignore_token: force creation of a non-tokenized address
*
* Return the interface's identifier for the EUI64 address generation mode.
* It's either a manually set token or and identifier generated in a
* hardware-specific way.
*
* Unless @ignore_token is set the token is preferred. That is the case
* for link-local addresses (to mimic kernel behavior).
*
* Returns: #TRUE if the @iid could be set
*/
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
static gboolean
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
nm_device_get_ip_iface_identifier (NMDevice *self, NMUtilsIPv6IfaceId *iid, gboolean ignore_token)
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
{
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
NMSettingIP6Config *s_ip6;
const char *token = NULL;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
device: allow ipv6ll address to be set for disconnected devices Commit f85941ee9101 ("device: don't try to generate ipv6ll address for disconnected devices") disabled the generation of IPv6 link-local addresses for disconnected devices to fix a crash. However that broke the following: $ ip a f dev eth0 $ systemctl start NetworkManager $ nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet disconnected eth0 $ ip a a dev eth0 2001::42/64 $ ip a show eth0 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:52:00:61:32:81 brd ff:ff:ff:ff:ff:ff inet6 2001::42/64 scope global valid_lft forever preferred_lft forever (no link-local address) Instead, enable the generation of a link-local address even if the device is disconnected and fix nm_device_get_ip_iface_identifier() to not require a connection if @ignore_token is set. Fixes: f85941ee91017079f30afac80e7b39c44cb04c81
2016-07-07 16:29:25 +02:00
if (!ignore_token) {
s_ip6 = (NMSettingIP6Config *)
core: make dad_counter argument guint32 type The dad_counter is hashed into the resulting address. Since we want the hashing to be independent of the architecture, we always hash 32 bit of dad_counter. Make the dad_counter argument of type guint32 for consistency. In practice this has no effect because: - for all our (current!) architectues, guint is the same as guint32. - all callers of nm_utils_ipv6_addr_set_stable_privacy() keep their dad-counter argument as guint8, so they never even pass numbers larger then 255. - nm_utils_ipv6_addr_set_stable_privacy() limits dad_counter further against RFC7217_IDGEN_RETRIES.
2017-04-27 13:58:38 +02:00
nm_device_get_applied_setting (self, NM_TYPE_SETTING_IP6_CONFIG);
device: allow ipv6ll address to be set for disconnected devices Commit f85941ee9101 ("device: don't try to generate ipv6ll address for disconnected devices") disabled the generation of IPv6 link-local addresses for disconnected devices to fix a crash. However that broke the following: $ ip a f dev eth0 $ systemctl start NetworkManager $ nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet disconnected eth0 $ ip a a dev eth0 2001::42/64 $ ip a show eth0 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:52:00:61:32:81 brd ff:ff:ff:ff:ff:ff inet6 2001::42/64 scope global valid_lft forever preferred_lft forever (no link-local address) Instead, enable the generation of a link-local address even if the device is disconnected and fix nm_device_get_ip_iface_identifier() to not require a connection if @ignore_token is set. Fixes: f85941ee91017079f30afac80e7b39c44cb04c81
2016-07-07 16:29:25 +02:00
g_return_val_if_fail (s_ip6, FALSE);
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
token = nm_setting_ip6_config_get_token (s_ip6);
device: allow ipv6ll address to be set for disconnected devices Commit f85941ee9101 ("device: don't try to generate ipv6ll address for disconnected devices") disabled the generation of IPv6 link-local addresses for disconnected devices to fix a crash. However that broke the following: $ ip a f dev eth0 $ systemctl start NetworkManager $ nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet disconnected eth0 $ ip a a dev eth0 2001::42/64 $ ip a show eth0 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:52:00:61:32:81 brd ff:ff:ff:ff:ff:ff inet6 2001::42/64 scope global valid_lft forever preferred_lft forever (no link-local address) Instead, enable the generation of a link-local address even if the device is disconnected and fix nm_device_get_ip_iface_identifier() to not require a connection if @ignore_token is set. Fixes: f85941ee91017079f30afac80e7b39c44cb04c81
2016-07-07 16:29:25 +02:00
}
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
if (token)
return nm_utils_ipv6_interface_identifier_get_from_token (iid, token);
else
return NM_DEVICE_GET_CLASS (self)->get_ip_iface_identifier (self, iid);
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
const char *
nm_device_get_driver (NMDevice *self)
{
g_return_val_if_fail (self != NULL, NULL);
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
return NM_DEVICE_GET_PRIVATE (self)->driver;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
core: add driver-version, firmware-version properties to NMDevice (bgo #636124) The info is extracted via SIOCETHTOOL ioctl() syscall using ETHTOOL_GDRVINFO. This works for most drivers but not all, e.g. for modems. We may figure out how to get the info for specific devices, and enhance the solution by implementing specific functions for particular device types later.
2012-06-01 16:48:57 +02:00
const char *
nm_device_get_driver_version (NMDevice *self)
{
g_return_val_if_fail (self != NULL, NULL);
return NM_DEVICE_GET_PRIVATE (self)->driver_version;
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
NMDeviceType
nm_device_get_device_type (NMDevice *self)
{
2008-06-10 Dan Williams <dcbw@redhat.com> The grand 802-3-ethernet rename. Get rid of the 802-3/8023/802_3 bits. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3741 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-06-10 15:54:23 +00:00
g_return_val_if_fail (NM_IS_DEVICE (self), NM_DEVICE_TYPE_UNKNOWN);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
return NM_DEVICE_GET_PRIVATE (self)->type;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
NMLinkType
nm_device_get_link_type (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), NM_LINK_TYPE_UNKNOWN);
return NM_DEVICE_GET_PRIVATE (self)->link_type;
}
core,libnm: add 'metered' property to NMDevice
2015-04-29 16:34:38 +02:00
/**
* nm_device_get_metered:
* @setting: the #NMDevice
*
* Returns: the #NMDevice:metered property of the device.
*
* Since: 1.2
**/
NMMetered
nm_device_get_metered (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), NM_METERED_UNKNOWN);
return NM_DEVICE_GET_PRIVATE (self)->metered;
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: refactor function nm_device_get_priority() / _get_route_metric_default() The name nm_device_get_priority() is misleading. Nowadays it's only used for the default route metric, and nothing else. Rename it, and make it static.
2017-09-28 15:06:28 +02:00
static guint32
_get_route_metric_default (NMDevice *self)
2008-09-30 Tambet Ingo <tambet@gmail.com> * src/nm-device.c (nm_device_get_priority): Implement. (nm_device_set_ip4_config): Send the device priority to system ip4 config setter. * src/NetworkManagerSystem.c (nm_system_device_set_from_ip4_config): Add priority argument and if it's >= 0, set the priority of the network route added automatically by netlink (or kernel?). (nm_system_device_set_priority): Implement. * src/NetworkManagerPolicy.c (get_best_device): Use nm_device_get_priority() instead of home-grown version. Revert the meaning, best priority is the lowest one. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4125 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-09-30 15:04:10 +00:00
{
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
/* Device 'priority' is used for the default route-metric and is based on
* the device type. The settings ipv4.route-metric and ipv6.route-metric
* can overwrite this default.
core: clarify device routing priority Instead of using the device's type number, which is a poor measure of routing priority since it has nothing to do with routing priority, let's make the decision more explicit.
2012-05-17 17:01:50 -05:00
*
device: refactor function nm_device_get_priority() / _get_route_metric_default() The name nm_device_get_priority() is misleading. Nowadays it's only used for the default route metric, and nothing else. Rename it, and make it static.
2017-09-28 15:06:28 +02:00
* For both IPv4 and IPv6 we use the same default values.
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
*
* The route-metric is used for the metric of the routes of device.
* This also applies to the default route. Therefore it affects also
* which device is the "best".
*
* For comparison, note that iproute2 by default adds IPv4 routes with
* metric 0, and IPv6 routes with metric 1024. The latter is the IPv6
core: rename NM_PLATFORM_ROUTE_METRIC_DEFAULT to NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP6 For IPv4, iproute for example defaults to a metric of 0. Hence, the name NM_PLATFORM_ROUTE_METRIC_DEFAULT was misleading. Also add a NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP4 define for completeness. https://bugzilla.gnome.org/show_bug.cgi?id=740780
2014-11-26 20:47:44 +01:00
* "user default" in the kernel (NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP6).
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
* In kernel, the full uint32_t range is available for route
* metrics (except for IPv6, where 0 means 1024).
core: clarify device routing priority Instead of using the device's type number, which is a poor measure of routing priority since it has nothing to do with routing priority, let's make the decision more explicit.
2012-05-17 17:01:50 -05:00
*/
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
switch (nm_device_get_device_type (self)) {
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
/* 50 is reserved for VPN (NM_VPN_ROUTE_METRIC_DEFAULT) */
core: clarify device routing priority Instead of using the device's type number, which is a poor measure of routing priority since it has nothing to do with routing priority, let's make the decision more explicit.
2012-05-17 17:01:50 -05:00
case NM_DEVICE_TYPE_ETHERNET:
device: the veth should have the same priority as ethernet It's supposed to be a virtual ethernet.
2016-02-24 17:37:50 +01:00
case NM_DEVICE_TYPE_VETH:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 100;
core,libnm: introduce NMDeviceMacsec At the moment the device only exposes the current link status, but cannot create new links.
2016-06-30 18:20:22 +02:00
case NM_DEVICE_TYPE_MACSEC:
return 125;
core: clarify device routing priority Instead of using the device's type number, which is a poor measure of routing priority since it has nothing to do with routing priority, let's make the decision more explicit.
2012-05-17 17:01:50 -05:00
case NM_DEVICE_TYPE_INFINIBAND:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 150;
core: clarify device routing priority Instead of using the device's type number, which is a poor measure of routing priority since it has nothing to do with routing priority, let's make the decision more explicit.
2012-05-17 17:01:50 -05:00
case NM_DEVICE_TYPE_ADSL:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 200;
core: clarify device routing priority Instead of using the device's type number, which is a poor measure of routing priority since it has nothing to do with routing priority, let's make the decision more explicit.
2012-05-17 17:01:50 -05:00
case NM_DEVICE_TYPE_WIMAX:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 250;
core: clarify device routing priority Instead of using the device's type number, which is a poor measure of routing priority since it has nothing to do with routing priority, let's make the decision more explicit.
2012-05-17 17:01:50 -05:00
case NM_DEVICE_TYPE_BOND:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 300;
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
case NM_DEVICE_TYPE_TEAM:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 350;
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
case NM_DEVICE_TYPE_VLAN:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 400;
device/macvlan: support device creation
2015-10-01 11:06:42 +02:00
case NM_DEVICE_TYPE_MACVLAN:
return 410;
device: adjust default route metric for BRIDGE device type We forgot to include the BRIDGE, so that bridge devices got a default priority (route-metric) of 950 Add it between VLAN and MODEM type. Also return a different metric for UNKNOWN device types, but these priorities are not actually expected.
2015-01-22 18:47:32 +01:00
case NM_DEVICE_TYPE_BRIDGE:
return 425;
device/tun: support device creation Allow the creation of a new TUN/TAP interface when a tun connection is activated.
2015-09-15 15:08:06 +02:00
case NM_DEVICE_TYPE_TUN:
return 450;
device: add NMDevicePPP The new device type represents a PPP interface, and will implement the activation of new-style PPPoE connections, i.e. the ones that don't claim the parent device.
2017-06-06 15:55:08 +02:00
case NM_DEVICE_TYPE_PPP:
return 460;
device/vxlan: support device creation
2015-10-14 10:52:09 +02:00
case NM_DEVICE_TYPE_VXLAN:
return 500;
core: add support for dummy devices Add support for creating dummy devices. This commit adds a D-Bus interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used primarily for determining the device type but does not carry any properties.
2017-01-31 14:14:33 +01:00
case NM_DEVICE_TYPE_DUMMY:
return 550;
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
case NM_DEVICE_TYPE_WIFI:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 600;
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
case NM_DEVICE_TYPE_OLPC_MESH:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 650;
device: add NMDeviceIPTunnel The new object type represents tunnels over IPv4 and IPv6. We have a single setting type (NMSettingIPTunnel) for tunnels and it can't be shared among different device factories. So we define also a single device type for all tunnels. This new object will also represent GRE tunnels, which before were instantiated as NMDeviceGre and had a ".Device.Gre" D-Bus interface. This commit introduces a change in behavior.
2015-10-30 15:14:23 +01:00
case NM_DEVICE_TYPE_IP_TUNNEL:
return 675;
device: prefer wifi over wwan by default This makes wifi preferred to wwan (the modem and bluetooth device types to be specific) by default, so that users that care about being connected at all times can keep both enabled with auto-connect. As wifi is usually unmetered and often faster than wwan, it makes sense to prefer it. This is also how pretty much every smart-phone in the world behaves, so it aligns better with user expectations too. https://bugzilla.gnome.org/show_bug.cgi?id=744754
2015-07-21 11:37:10 +02:00
case NM_DEVICE_TYPE_MODEM:
return 700;
case NM_DEVICE_TYPE_BT:
return 750;
introspection: add o.fd.NM.Device.OvsBridge interface
2017-10-02 08:39:09 +02:00
case NM_DEVICE_TYPE_OVS_BRIDGE:
introspection: add o.fd.NM.Device.OvsInterface interface
2017-10-02 08:39:09 +02:00
case NM_DEVICE_TYPE_OVS_INTERFACE:
introspection: add o.fd.NM.Device.OvsPort interface
2017-10-02 08:39:09 +02:00
case NM_DEVICE_TYPE_OVS_PORT:
introspection: add o.fd.NM.Device.OvsInterface interface
2017-10-02 08:39:09 +02:00
return 800;
device: adjust default route metric for BRIDGE device type We forgot to include the BRIDGE, so that bridge devices got a default priority (route-metric) of 950 Add it between VLAN and MODEM type. Also return a different metric for UNKNOWN device types, but these priorities are not actually expected.
2015-01-22 18:47:32 +01:00
case NM_DEVICE_TYPE_GENERIC:
core: adjust values for default route-metrics per device type We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
2014-11-26 19:35:12 +01:00
return 950;
device: adjust default route metric for BRIDGE device type We forgot to include the BRIDGE, so that bridge devices got a default priority (route-metric) of 950 Add it between VLAN and MODEM type. Also return a different metric for UNKNOWN device types, but these priorities are not actually expected.
2015-01-22 18:47:32 +01:00
case NM_DEVICE_TYPE_UNKNOWN:
return 10000;
case NM_DEVICE_TYPE_UNUSED1:
case NM_DEVICE_TYPE_UNUSED2:
/* omit default: to get compiler warning about missing switch cases */
break;
core: clarify device routing priority Instead of using the device's type number, which is a poor measure of routing priority since it has nothing to do with routing priority, let's make the decision more explicit.
2012-05-17 17:01:50 -05:00
}
device: adjust default route metric for BRIDGE device type We forgot to include the BRIDGE, so that bridge devices got a default priority (route-metric) of 950 Add it between VLAN and MODEM type. Also return a different metric for UNKNOWN device types, but these priorities are not actually expected.
2015-01-22 18:47:32 +01:00
return 11000;
2008-09-30 Tambet Ingo <tambet@gmail.com> * src/nm-device.c (nm_device_get_priority): Implement. (nm_device_set_ip4_config): Send the device priority to system ip4 config setter. * src/NetworkManagerSystem.c (nm_system_device_set_from_ip4_config): Add priority argument and if it's >= 0, set the priority of the network route added automatically by netlink (or kernel?). (nm_system_device_set_priority): Implement. * src/NetworkManagerPolicy.c (get_best_device): Use nm_device_get_priority() instead of home-grown version. Revert the meaning, best priority is the lowest one. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4125 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-09-30 15:04:10 +00:00
}
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
static gboolean
default_route_metric_penalty_detect (NMDevice *self)
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
{
device: add default route penalty only if concheck is enabled If we don't have connection checking functionality just avoid adding a penalty to the defaut route of newly activated connections.
2017-05-03 18:05:44 +02:00
#if WITH_CONCHECK
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: avoid integer overflow with route-metric penalty
2017-05-02 18:19:08 +02:00
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
/* currently we don't differentiate between IPv4 and IPv6 when detecting
* connectivity. */
device: add default route penalty only if concheck is enabled If we don't have connection checking functionality just avoid adding a penalty to the defaut route of newly activated connections.
2017-05-03 18:05:44 +02:00
if ( priv->connectivity_state != NM_CONNECTIVITY_FULL
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
&& nm_connectivity_check_enabled (nm_connectivity_get ())) {
return TRUE;
device: avoid integer overflow with route-metric penalty
2017-05-02 18:19:08 +02:00
}
device: add default route penalty only if concheck is enabled If we don't have connection checking functionality just avoid adding a penalty to the defaut route of newly activated connections.
2017-05-03 18:05:44 +02:00
#endif
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
return FALSE;
}
static guint32
default_route_metric_penalty_get (NMDevice *self, int addr_family)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
nm_assert_addr_family (addr_family);
if ( addr_family == AF_INET
? priv->default_route_metric_penalty_ip4_has
: priv->default_route_metric_penalty_ip6_has)
return 20000;
return 0;
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
}
device: expose nm_device_get_ip_route_metric() function Will be used later.
2017-08-30 19:10:15 +02:00
guint32
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (NMDevice *self,
int addr_family)
core: add explicit functions for the route priority/metric Before, we would always call unanimously nm_device_get_priority() to get the default route metric for a device. Add new functions nm_device_get_ip4_route_priority() and nm_device_get_ip6_route_priority() and use them at the proper places. Also add new function nm_vpn_connection_get_ip4_route_metric() and nm_vpn_connection_get_ip6_route_metric(). Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-28 18:11:35 +02:00
{
device: make route-metric configurable per-device The route-metric can be configured per connection via the ipv4.route-metric and ipv6.route-metric fields. When the value is left at -1 (the default), we would determine the route-metric based on the device type (nm_device_get_priority()). Extend that scheme by making the default value overwritable in NetworkManager.conf.
2015-05-15 12:21:59 +02:00
char *value;
gint64 route_metric;
NMSettingIPConfig *s_ip;
core: overwrite the default route priority via connection setting Make use of the new setting nm_setting_ip_config_get_route_metric() If set, this override the route metric determined based on the device type. Similarly for VPN also prefer the setting from the connection. Thereby change the default priority (for VPN that have their own device) to NM_VPN_ROUTE_METRIC_DEFAULT instead of NM_PLATFORM_ROUTE_METRIC_DEFAULT. The latter would be a very low priority compared to the default metrics for devices. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-28 18:32:05 +02:00
NMConnection *connection;
g_return_val_if_fail (NM_IS_DEVICE (self), G_MAXUINT32);
device: expose nm_device_get_ip_route_metric() function Will be used later.
2017-08-30 19:10:15 +02:00
g_return_val_if_fail (NM_IN_SET (addr_family, AF_INET, AF_INET6), G_MAXUINT32);
core: overwrite the default route priority via connection setting Make use of the new setting nm_setting_ip_config_get_route_metric() If set, this override the route metric determined based on the device type. Similarly for VPN also prefer the setting from the connection. Thereby change the default priority (for VPN that have their own device) to NM_VPN_ROUTE_METRIC_DEFAULT instead of NM_PLATFORM_ROUTE_METRIC_DEFAULT. The latter would be a very low priority compared to the default metrics for devices. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-28 18:32:05 +02:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
device: make route-metric configurable per-device The route-metric can be configured per connection via the ipv4.route-metric and ipv6.route-metric fields. When the value is left at -1 (the default), we would determine the route-metric based on the device type (nm_device_get_priority()). Extend that scheme by making the default value overwritable in NetworkManager.conf.
2015-05-15 12:21:59 +02:00
if (connection) {
device: expose nm_device_get_ip_route_metric() function Will be used later.
2017-08-30 19:10:15 +02:00
s_ip = addr_family == AF_INET
device: make route-metric configurable per-device The route-metric can be configured per connection via the ipv4.route-metric and ipv6.route-metric fields. When the value is left at -1 (the default), we would determine the route-metric based on the device type (nm_device_get_priority()). Extend that scheme by making the default value overwritable in NetworkManager.conf.
2015-05-15 12:21:59 +02:00
? nm_connection_get_setting_ip4_config (connection)
: nm_connection_get_setting_ip6_config (connection);
/* Slave interfaces don't have IP settings, but we may get here when
* external changes are made or when noticing IP changes when starting
* the slave connection.
*/
if (s_ip) {
route_metric = nm_setting_ip_config_get_route_metric (s_ip);
if (route_metric >= 0)
goto out;
}
}
device: don't assume valid ip4/ip6 config in nm_device_get_ipX_route_metric() These functions will sometimes get called on updates to the device's IP config due to external changes, or when addresses get flushed from the device when activating it. If the device is a slave device, then at this point its NMConnection won't have an IP settings. Suppress the warning that gets printed when s_ip == NULL, because it's expected.
2015-03-12 15:04:16 -05:00
device: make route-metric configurable per-device The route-metric can be configured per connection via the ipv4.route-metric and ipv6.route-metric fields. When the value is left at -1 (the default), we would determine the route-metric based on the device type (nm_device_get_priority()). Extend that scheme by making the default value overwritable in NetworkManager.conf.
2015-05-15 12:21:59 +02:00
/* use the current NMConfigData, which makes this configuration reloadable.
* Note that that means that the route-metric might change between SIGHUP.
* You must cache the returned value if that is a problem. */
config: add macros NM_CONFIG_GET_DATA and NM_CONFIG_GET_DATA_ORIG
2015-06-09 08:47:41 +02:00
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
device: expose nm_device_get_ip_route_metric() function Will be used later.
2017-08-30 19:10:15 +02:00
addr_family == AF_INET ? "ipv4.route-metric" : "ipv6.route-metric", self);
device: make route-metric configurable per-device The route-metric can be configured per connection via the ipv4.route-metric and ipv6.route-metric fields. When the value is left at -1 (the default), we would determine the route-metric based on the device type (nm_device_get_priority()). Extend that scheme by making the default value overwritable in NetworkManager.conf.
2015-05-15 12:21:59 +02:00
if (value) {
route_metric = _nm_utils_ascii_str_to_int64 (value, 10, 0, G_MAXUINT32, -1);
g_free (value);
if (route_metric >= 0)
goto out;
}
device: refactor function nm_device_get_priority() / _get_route_metric_default() The name nm_device_get_priority() is misleading. Nowadays it's only used for the default route metric, and nothing else. Rename it, and make it static.
2017-09-28 15:06:28 +02:00
route_metric = _get_route_metric_default (self);
device: make route-metric configurable per-device The route-metric can be configured per connection via the ipv4.route-metric and ipv6.route-metric fields. When the value is left at -1 (the default), we would determine the route-metric based on the device type (nm_device_get_priority()). Extend that scheme by making the default value overwritable in NetworkManager.conf.
2015-05-15 12:21:59 +02:00
out:
device: expose nm_device_get_ip_route_metric() function Will be used later.
2017-08-30 19:10:15 +02:00
return nm_utils_ip_route_metric_normalize (addr_family, route_metric);
core: add explicit functions for the route priority/metric Before, we would always call unanimously nm_device_get_priority() to get the default route metric for a device. Add new functions nm_device_get_ip4_route_priority() and nm_device_get_ip6_route_priority() and use them at the proper places. Also add new function nm_vpn_connection_get_ip4_route_metric() and nm_vpn_connection_get_ip6_route_metric(). Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-28 18:11:35 +02:00
}
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
guint32
nm_device_get_route_table (NMDevice *self,
int addr_family,
gboolean fallback_main)
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
{
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
NMDevicePrivate *priv;
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
NMConnection *connection;
NMSettingIPConfig *s_ip;
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
guint32 route_table = 0;
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
nm_assert_addr_family (addr_family);
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), RT_TABLE_MAIN);
priv = NM_DEVICE_GET_PRIVATE (self);
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
/* the route table setting affects how we sync routes. We shall
* not change it while the device is active, hence, cache it. */
if (addr_family == AF_INET) {
if (priv->v4_route_table_initalized)
return priv->v4_route_table ?: (fallback_main ? RT_TABLE_MAIN : 0);
} else {
if (priv->v6_route_table_initalized)
return priv->v6_route_table ?: (fallback_main ? RT_TABLE_MAIN : 0);
}
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
connection = nm_device_get_applied_connection (self);
if (connection) {
if (addr_family == AF_INET)
s_ip = nm_connection_get_setting_ip4_config (connection);
else
s_ip = nm_connection_get_setting_ip6_config (connection);
if (s_ip)
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
route_table = nm_setting_ip_config_get_route_table (s_ip);
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
/* we only lookup the global default if we also have an applied
* connection. Otherwise, the connection is not active, and the
* connection default doesn't matter. */
if (route_table == 0) {
gs_free char *value = NULL;
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
addr_family == AF_INET
? "ipv4.route-table"
: "ipv6.route-table",
self);
route_table = _nm_utils_ascii_str_to_int64 (value, 10, 0, G_MAXUINT32, 0);
}
}
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
if (addr_family == AF_INET) {
priv->v4_route_table_initalized = TRUE;
priv->v4_route_table = route_table;
} else {
priv->v6_route_table_initalized = TRUE;
priv->v6_route_table = route_table;
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
}
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
_LOGT (LOGD_DEVICE,
"ipv%c.route-table = %u%s",
addr_family == AF_INET ? '4' : '6',
(guint) (route_table ?: RT_TABLE_MAIN),
route_table ? "" : " (policy routing not enabled)");
return route_table ?: (fallback_main ? RT_TABLE_MAIN : 0);
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
}
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
const NMPObject *
nm_device_get_best_default_route (NMDevice *self,
int addr_family)
device: refactor clearing default-route in NMDevice Add a function _update_default_route() to set the default_route flags and call update() in one step. Also, if there are no changes, skip the call to NMDefaultRouteManager's update().
2016-04-15 17:43:17 +02:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
switch (addr_family) {
case AF_INET:
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
return priv->ip4_config ? nm_ip4_config_best_default_route_get (priv->ip4_config) : NULL;
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
case AF_INET6:
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
return priv->ip6_config ? nm_ip6_config_best_default_route_get (priv->ip6_config) : NULL;
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
case AF_UNSPEC:
return (priv->ip4_config ? nm_ip4_config_best_default_route_get (priv->ip4_config) : NULL)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
?: (priv->ip6_config ? nm_ip6_config_best_default_route_get (priv->ip6_config) : NULL);
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
default:
g_return_val_if_reached (NULL);
device: refactor clearing default-route in NMDevice Add a function _update_default_route() to set the default_route flags and call update() in one step. Also, if there are no changes, skip the call to NMDefaultRouteManager's update().
2016-04-15 17:43:17 +02:00
}
policy: add manager for default routes and support multiple default routes Up to now, NMPolicy would iterate over all devices to find the "best" device and assign the default route to that device. A better approach is to add a default route to *all* devices that are never-default=no. The relative priority is choosen according to the route metrics. If two devices receive the same metric, we want to prefer the device that activates first. That way, the default route sticks to the same device until a better device activates or the device deactivates. Hence, the order of activation is imporant in this case (as it is already now). Also, if several devices have identical metrics, increment their metrics so that every metric is unique. This makes the routing deterministic according to what we choose as best device. A special case is assumed devices. In this case we cannot adjust the metric in face of equal metrics. Add a new singleton class NMDefaultRouteManager that has a list of all devices and their default routes. The manager will order the devices by their priority and configure the routes using platform. Also update the metric for VPN connections. Later we will track VPN routes also via NMDefaultRouteManager. For now, fix the VPN metric because otherwise VPNs would always get metric 1024 (which is usually much larger then the device metrics). https://bugzilla.gnome.org/show_bug.cgi?id=735512 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-29 00:03:47 +02:00
}
core: add a 'type-desc' property to NMDeviceInterface and use it instead of littering the code with NM_IS_*.
2009-07-07 14:24:12 -04:00
const char *
nm_device_get_type_desc (NMDevice *self)
{
g_return_val_if_fail (self != NULL, NULL);
core: use NMDevicePrivate everywhere
2009-07-07 14:34:01 -04:00
return NM_DEVICE_GET_PRIVATE (self)->type_desc;
core: add a 'type-desc' property to NMDeviceInterface and use it instead of littering the code with NM_IS_*.
2009-07-07 14:24:12 -04:00
}
device: add nm_device_get_type_description() function Add a function to get a concise representation of the device type. libnm already has nm_device_get_type_description() for that and it is shown by nmcli -f GENERAL.TYPE device show Reimplement that function for nm-core. Just take care that the two implementations don't diverge.
2015-05-15 15:00:07 +02:00
const char *
nm_device_get_type_description (NMDevice *self)
{
g_return_val_if_fail (self != NULL, NULL);
/* Beware: this function should return the same
* value as nm_device_get_type_description() in libnm. */
return NM_DEVICE_GET_CLASS (self)->get_type_description (self);
}
static const char *
get_type_description (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if (!priv->type_description) {
const char *typename;
typename = G_OBJECT_TYPE_NAME (self);
if (g_str_has_prefix (typename, "NMDevice"))
typename += 8;
priv->type_description = g_ascii_strdown (typename, -1);
}
return priv->type_description;
}
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_has_carrier (NMDevice *self)
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
return NM_DEVICE_GET_PRIVATE (self)->carrier;
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
}
NMActRequest *
nm_device_get_act_request (NMDevice *self)
{
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
return NM_DEVICE_GET_PRIVATE (self)->act_request;
}
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
NMSettingsConnection *
nm_device_get_settings_connection (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
return priv->act_request ? nm_act_request_get_settings_connection (priv->act_request) : NULL;
}
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
NMConnection *
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
nm_device_get_applied_connection (NMDevice *self)
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
{
device: refactor nm_device_get_applied_setting()
2016-06-02 22:16:54 +02:00
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
priv = NM_DEVICE_GET_PRIVATE (self);
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
return priv->act_request ? nm_act_request_get_applied_connection (priv->act_request) : NULL;
}
gboolean
nm_device_has_unmodified_applied_connection (NMDevice *self, NMSettingCompareFlags compare_flags)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if (!priv->act_request)
return FALSE;
return nm_active_connection_has_unmodified_applied_connection ((NMActiveConnection *) priv->act_request, compare_flags);
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
}
device: add nm_device_get_applied_setting()
2016-02-11 21:33:15 +01:00
NMSetting *
device: refactor nm_device_get_applied_setting()
2016-06-02 22:16:54 +02:00
nm_device_get_applied_setting (NMDevice *self, GType setting_type)
device: add nm_device_get_applied_setting()
2016-02-11 21:33:15 +01:00
{
device: refactor nm_device_get_applied_setting()
2016-06-02 22:16:54 +02:00
NMConnection *connection;
device: add nm_device_get_applied_setting()
2016-02-11 21:33:15 +01:00
device: refactor nm_device_get_applied_setting()
2016-06-02 22:16:54 +02:00
connection = nm_device_get_applied_connection (self);
return connection ? nm_connection_get_setting (connection, setting_type) : NULL;
device: add nm_device_get_applied_setting()
2016-02-11 21:33:15 +01:00
}
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
RfKillType
nm_device_get_rfkill_type (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
return NM_DEVICE_GET_PRIVATE (self)->rfkill_type;
}
static const char *
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_get_physical_port_id (NMDevice *self)
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
return NM_DEVICE_GET_PRIVATE (self)->physical_port_id;
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
static void
update_connectivity_state (NMDevice *self, NMConnectivityState state)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
/* If the connectivity check is disabled, make an optimistic guess. */
if (state == NM_CONNECTIVITY_UNKNOWN) {
if (priv->state == NM_DEVICE_STATE_ACTIVATED) {
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
if (nm_device_get_best_default_route (self, AF_UNSPEC))
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
state = NM_CONNECTIVITY_FULL;
else
state = NM_CONNECTIVITY_LIMITED;
} else {
state = NM_CONNECTIVITY_NONE;
}
}
if (priv->connectivity_state != state) {
#if WITH_CONCHECK
_LOGD (LOGD_CONCHECK, "state changed from %s to %s",
nm_connectivity_state_to_string (priv->connectivity_state),
nm_connectivity_state_to_string (state));
#endif
priv->connectivity_state = state;
_notify (self, PROP_CONNECTIVITY);
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
device: apply route metric penality only when the default route exists It's useless (and in some cases also harmful) to commit the configuration to update the default route metric when the device has no default route. Also, don't commit configuration for externally activated devices. https://bugzilla.redhat.com/show_bug.cgi?id=1459604
2017-06-08 00:26:00 +02:00
if ( priv->state == NM_DEVICE_STATE_ACTIVATED
&& !nm_device_sys_iface_state_is_external (self)) {
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
if ( nm_device_get_best_default_route (self, AF_INET)
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
&& !ip4_config_merge_and_apply (self, TRUE))
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
_LOGW (LOGD_IP4, "Failed to update IPv4 route metric");
if ( nm_device_get_best_default_route (self, AF_INET6)
device: apply route metric penality only when the default route exists It's useless (and in some cases also harmful) to commit the configuration to update the default route metric when the device has no default route. Also, don't commit configuration for externally activated devices. https://bugzilla.redhat.com/show_bug.cgi?id=1459604
2017-06-08 00:26:00 +02:00
&& !ip6_config_merge_and_apply (self, TRUE))
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
_LOGW (LOGD_IP6, "Failed to update IPv6 route metric");
device: don't update disconnected devices routes after connectivity check When the device is not activated it does not make sense to try to update its default route metric based on connectivity status. Fixes the following: nm_ip4_config_commit: assertion 'ifindex > 0' failed #0 raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 #1 g_logv (breakpoint=1) at gmessages.c:324 #2 g_logv (log_domain=<> "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=<optimized out>) at gmessages.c:1081 #3 g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1119 #4 g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at gmessages.c:1128 #5 nm_ip4_config_commit (config=<> [NMIP4Config], ifindex=<optimized out>, routes_full_sync=<optimized out>, default_route_metric=-1) at src/nm-ip4-config.c:339 #6 nm_device_set_ip4_config (self=<> [NMDeviceTun], new_config=<> [NMIP4Config], default_route_metric=450, commit=1, routes_full_sync=<optimized out>) at src/devices/nm-device.c:9635 #7 ip4_config_merge_and_apply (self=<> [NMDeviceTun], config=0x0, commit=1) at src/devices/nm-device.c:5541 #8 update_connectivity_state (self=<> [NMDeviceTun], state=NM_CONNECTIVITY_NONE) at src/devices/nm-device.c:1743 #9 concheck_periodic_update (self=<> [NMDeviceTun]) at src/devices/nm-device.c:1872 #10 nm_device_set_ip4_config (self=<> [NMDeviceTun], new_config=0x0, default_route_metric=0, commit=1, routes_full_sync=1) at src/devices/nm-device.c:9669 #11 _cleanup_generic_post (self=<> [NMDeviceTun], cleanup_type=CLEANUP_TYPE_KEEP) at src/devices/nm-device.c:11863 #12 nm_device_cleanup (self=<> [NMDeviceTun], reason=NM_DEVICE_STATE_REASON_NOW_UNMANAGED, cleanup_type=<optimized out>) at src/devices/nm-device.c:12006 #13 _set_state_full (self=<> [NMDeviceTun], state=<optimized out>, reason=<optimized out>, quitting=<optimized out>) at src/devices/nm-device.c:12376 #14 nm_device_unrealize (self=<> [NMDeviceTun], remove_resources=<optimized out>, error=<>) at src/devices/nm-device.c:3183 #15 _platform_link_cb_idle (data=<>) at src/nm-manager.c:2359 #16 g_idle_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gmain.c:5439 #17 g_main_context_dispatch (context=<>) at gmain.c:3152 #18 g_main_context_dispatch (context=<>) at gmain.c:3767 #19 g_main_context_iterate (context=<>, block=1, dispatch=1, self=<optimized out>) a Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39 https://bugzilla.redhat.com/show_bug.cgi?id=1436978
2017-03-29 14:05:53 +02:00
}
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
}
}
typedef struct {
NMDevice *self;
NMDeviceConnectivityCallback callback;
gpointer user_data;
guint64 seq;
} ConnectivityCheckData;
static void
concheck_done (ConnectivityCheckData *data)
{
NMDevice *self = data->self;
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
/* The unsolicited connectivity checks don't hook a callback. */
if (data->callback)
data->callback (data->self, priv->connectivity_state, data->user_data);
g_object_unref (data->self);
g_slice_free (ConnectivityCheckData, data);
}
#if WITH_CONCHECK
static void
concheck_cb (GObject *source_object, GAsyncResult *result, gpointer user_data)
{
ConnectivityCheckData *data = user_data;
NMDevice *self = data->self;
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnectivity *connectivity = NM_CONNECTIVITY (source_object);
NMConnectivityState state;
GError *error = NULL;
state = nm_connectivity_check_finish (connectivity, result, &error);
if (error) {
_LOGW (LOGD_DEVICE, "connectivity checking on '%s' failed: %s",
nm_device_get_iface (self), error->message);
g_error_free (error);
}
if (data->seq == priv->concheck_seq)
update_connectivity_state (data->self, state);
concheck_done (data);
}
#endif /* WITH_CONCHECK */
static gboolean
no_concheck (gpointer user_data)
{
ConnectivityCheckData *data = user_data;
concheck_done (data);
return G_SOURCE_REMOVE;
}
void
nm_device_check_connectivity (NMDevice *self,
NMDeviceConnectivityCallback callback,
gpointer user_data)
{
ConnectivityCheckData *data;
#if WITH_CONCHECK
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
#endif
data = g_slice_new0 (ConnectivityCheckData);
data->self = g_object_ref (self);
data->callback = callback;
data->user_data = user_data;
#if WITH_CONCHECK
if (priv->concheck_periodic_id) {
data->seq = ++priv->concheck_seq;
/* Kick off a real connectivity check. */
nm_connectivity_check_async (nm_connectivity_get (),
device: check connectivity on the IP interface curl must bind to the interface that has IP configuration, not the underlying device. Without this commit, connectivity check fails on certain connection types (PPPoE, WWAN). Fixes: 9d43869e473b47542520c807dace93a6f9520964
2017-06-08 00:23:05 +02:00
nm_device_get_ip_iface (self),
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
concheck_cb,
data);
return;
}
#endif
/* Fake one. */
g_idle_add (no_concheck, data);
}
NMConnectivityState
nm_device_get_connectivity_state (NMDevice *self)
{
device: avoid integer overflow with route-metric penalty
2017-05-02 18:19:08 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), NM_CONNECTIVITY_UNKNOWN);
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
device: avoid integer overflow with route-metric penalty
2017-05-02 18:19:08 +02:00
return NM_DEVICE_GET_PRIVATE (self)->connectivity_state;
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
}
#if WITH_CONCHECK
static void
concheck_periodic (NMConnectivity *connectivity, NMDevice *self)
{
nm_device_check_connectivity (self, NULL, NULL);
}
#endif
static void
concheck_periodic_update (NMDevice *self)
{
#if WITH_CONCHECK
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
gboolean check_enable;
check_enable = (priv->state == NM_DEVICE_STATE_ACTIVATED)
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
&& nm_device_get_best_default_route (self, AF_UNSPEC);
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
if (check_enable && !priv->concheck_periodic_id) {
/* We just gained a default route. Enable periodic checking. */
priv->concheck_periodic_id = g_signal_connect (nm_connectivity_get (),
NM_CONNECTIVITY_PERIODIC_CHECK,
G_CALLBACK (concheck_periodic), self);
/* Also kick off a check right away. */
nm_device_check_connectivity (self, NULL, NULL);
} else if (!check_enable && priv->concheck_periodic_id) {
/* The default route has gone off, and so has connectivity. */
g_signal_handler_disconnect (nm_connectivity_get (), priv->concheck_periodic_id);
priv->concheck_periodic_id = 0;
device: penalize default route metrics for connectivity failures This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
2017-03-27 15:22:22 +00:00
update_connectivity_state (self, NM_CONNECTIVITY_NONE);
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
}
#else
/* update_connectivity_state() figures out how to lie about
* connectivity state if the actual state is not really known. */
update_connectivity_state (self, NM_CONNECTIVITY_UNKNOWN);
#endif
}
/*****************************************************************************/
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
static SlaveInfo *
find_slave_info (NMDevice *self, NMDevice *slave)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
CList *iter;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
SlaveInfo *info;
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
c_list_for_each (iter, &priv->slaves) {
info = c_list_entry (iter, SlaveInfo, lst_slave);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
if (info->slave == slave)
return info;
}
return NULL;
}
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
/**
device/trivial: rename master related function of nm-device We have the master/slave related functions - for master device: - nm_device_master_add_slave() - nm_device_master_release_slaves() - nm_device_release_one_slave() - nm_device_enslave_slave() - for slave device: - nm_device_slave_notify_enslave() - nm_device_slave_notify_release() Rename the two that didn't match the pattern to - nm_device_master_release_one_slave() - nm_device_master_enslave_slave()
2015-08-06 14:37:12 +02:00
* nm_device_master_enslave_slave:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the master device
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
* @slave: the slave device to enslave
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
* @connection: (allow-none): the slave device's connection
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* If @self is capable of enslaving other devices (ie it's a bridge, bond, team,
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
* etc) then this function enslaves @slave.
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
*
* Returns: %TRUE on success, %FALSE on failure or if this device cannot enslave
* other devices.
*/
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
static gboolean
device/trivial: rename master related function of nm-device We have the master/slave related functions - for master device: - nm_device_master_add_slave() - nm_device_master_release_slaves() - nm_device_release_one_slave() - nm_device_enslave_slave() - for slave device: - nm_device_slave_notify_enslave() - nm_device_slave_notify_release() Rename the two that didn't match the pattern to - nm_device_master_release_one_slave() - nm_device_master_enslave_slave()
2015-08-06 14:37:12 +02:00
nm_device_master_enslave_slave (NMDevice *self, NMDevice *slave, NMConnection *connection)
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
{
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
SlaveInfo *info;
gboolean success = FALSE;
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
gboolean configure;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_val_if_fail (self != NULL, FALSE);
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
g_return_val_if_fail (slave != NULL, FALSE);
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_val_if_fail (NM_DEVICE_GET_CLASS (self)->enslave_slave != NULL, FALSE);
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
info = find_slave_info (self, slave);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
if (!info)
return FALSE;
device/trivial: rename fields to have unique names
2015-08-06 14:17:29 +02:00
if (info->slave_is_enslaved)
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
success = TRUE;
else {
configure = (info->configure && connection != NULL);
if (configure)
g_return_val_if_fail (nm_device_get_state (slave) >= NM_DEVICE_STATE_DISCONNECTED, FALSE);
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
success = NM_DEVICE_GET_CLASS (self)->enslave_slave (self, slave, connection, configure);
device/trivial: rename fields to have unique names
2015-08-06 14:17:29 +02:00
info->slave_is_enslaved = success;
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
}
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
nm_device_slave_notify_enslave (info->slave, success);
core: update hardware address when slaves change The hardware address of a device often changes when slaves change, for example with bond interfaces, which take the hardware address of their first slave. Make sure that's always up-to-date.
2013-01-18 14:34:40 -06:00
/* Ensure the device's hardware address is up-to-date; it often changes
* when slaves change.
*/
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_update_hw_address (self);
core: update hardware address when slaves change The hardware address of a device often changes when slaves change, for example with bond interfaces, which take the hardware address of their first slave. Make sure that's always up-to-date.
2013-01-18 14:34:40 -06:00
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
/* Restart IP configuration if we're waiting for slaves. Do this
* after updating the hardware address as IP config may need the
* new address.
*/
if (success) {
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
if (NM_DEVICE_GET_PRIVATE (self)->ip4_state == IP_WAIT)
nm_device_activate_stage3_ip4_start (self);
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
if (NM_DEVICE_GET_PRIVATE (self)->ip6_state == IP_WAIT)
nm_device_activate_stage3_ip6_start (self);
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
}
device: apply MTU setting also to devices without IPv4 configuration Usually the MTU in the ethernet.mtu property is applied to the device during the commit of IPv4 configuration. For devices with ipv4.method=disabled or slave devices that phase is skipped and so the setting does not have effect. Apply the MTU explicitly in such cases. https://bugzilla.redhat.com/show_bug.cgi?id=1303968 https://bugzilla.redhat.com/show_bug.cgi?id=1303731
2016-03-17 14:17:32 +01:00
/* Since slave devices don't have their own IP configuration,
* set the MTU here.
*/
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
_commit_mtu (slave, NM_DEVICE_GET_PRIVATE (slave)->ip4_config);
device: apply MTU setting also to devices without IPv4 configuration Usually the MTU in the ethernet.mtu property is applied to the device during the commit of IPv4 configuration. For devices with ipv4.method=disabled or slave devices that phase is skipped and so the setting does not have effect. Apply the MTU explicitly in such cases. https://bugzilla.redhat.com/show_bug.cgi?id=1303968 https://bugzilla.redhat.com/show_bug.cgi?id=1303731
2016-03-17 14:17:32 +01:00
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
return success;
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
}
/**
device/trivial: rename master related function of nm-device We have the master/slave related functions - for master device: - nm_device_master_add_slave() - nm_device_master_release_slaves() - nm_device_release_one_slave() - nm_device_enslave_slave() - for slave device: - nm_device_slave_notify_enslave() - nm_device_slave_notify_release() Rename the two that didn't match the pattern to - nm_device_master_release_one_slave() - nm_device_master_enslave_slave()
2015-08-06 14:37:12 +02:00
* nm_device_master_release_one_slave:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the master device
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
* @slave: the slave device to release
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @configure: whether @self needs to actually release @slave
device: fix warning releasing of slave when slave device gets removed When the slave device gets removed, the master is not in a state-change when calling nm_device_release_one_slave(). This triggers a warning [1]. [1] backtrace: #0 0x0000003370c504e9 in g_logv (log_domain=0x4c144c "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fff8b1d35b0) at gmessages.c:989 #1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x3370cc1fdc "%s") at gmessages.c:1025 #2 0x0000003370c50956 in g_warn_message (domain=domain@entry=0x4c144c "NetworkManager", file=file@entry=0x4b14d5 "devices/nm-device.c", line=line@entry=841, func=func@entry=0x4b48f0 <__FUNCTION__.35456> "nm_device_release_one_slave", warnexpr=warnexpr@entry=0x0) at gmessages.c:1058 #3 0x0000000000436c30 in nm_device_release_one_slave (dev=dev@entry=0xd92540, slave=slave@entry=0xdb0e50, configure=configure@entry=1) at devices/nm-device.c:841 #4 0x000000000043a779 in slave_state_changed (slave=0xdb0e50, slave_new_state=NM_DEVICE_STATE_UNMANAGED, slave_old_state=NM_DEVICE_STATE_ACTIVATED, reason=<optimized out>, self=0xd92540) at devices/nm-device.c:1214 #5 0x0000003371805d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76 #6 0x00000033718056bc in ffi_call (cif=cif@entry=0x7fff8b1d3a00, fn=0x43a677 <slave_state_changed>, rvalue=0x7fff8b1d3970, avalue=avalue@entry=0x7fff8b1d38f0) at ../src/x86/ffi64.c:522 #7 0x0000003371c10ad8 in g_cclosure_marshal_generic (closure=0xd76120, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454 #8 0x0000003371c10298 in g_closure_invoke (closure=0xd76120, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fff8b1d3c00, invocation_hint=invocation_hint@entry=0x7fff8b1d3ba0) at gclosure.c:777 #9 0x0000003371c2235d in signal_emit_unlocked_R (node=node@entry=0xd9d850, detail=detail@entry=0, instance=instance@entry=0xdb0e50, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff8b1d3c00) at gsignal.c:3586 #10 0x0000003371c2a0f2 in g_signal_emit_valist (instance=instance@entry=0xdb0e50, signal_id=signal_id@entry=68, detail=detail@entry=0, var_args=var_args@entry=0x7fff8b1d3e38) at gsignal.c:3330 #11 0x0000003371c2a8f8 in g_signal_emit_by_name (instance=instance@entry=0xdb0e50, detailed_signal=detailed_signal@entry=0x4c3ce2 "state-changed") at gsignal.c:3426 #12 0x000000000043754f in _set_state_full (device=device@entry=0xdb0e50, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6689 #13 0x000000000043797c in nm_device_state_changed (device=device@entry=0xdb0e50, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823 #14 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0xdb0e50, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983 #15 0x00000000004799c2 in remove_device (manager=manager@entry=0xd86150, device=0xdb0e50, quitting=quitting@entry=0) at nm-manager.c:769 #16 0x000000000047e3bf in platform_link_cb (platform=<optimized out>, ifindex=35, plink=<optimized out>, change_type=<optimized out>, reason=<optimized out>, user_data=<optimized out>) at nm-manager.c:2123 #17 0x0000003371805d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76 #18 0x00000033718056bc in ffi_call (cif=cif@entry=0x7fff8b1d4320, fn=0x47e34b <platform_link_cb>, rvalue=0x7fff8b1d4290, avalue=avalue@entry=0x7fff8b1d4210) at ../src/x86/ffi64.c:522 #19 0x0000003371c10ad8 in g_cclosure_marshal_generic (closure=0xd32e40, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454 #20 0x0000003371c10298 in g_closure_invoke (closure=0xd32e40, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff8b1d4520, invocation_hint=invocation_hint@entry=0x7fff8b1d44c0) at gclosure.c:777 #21 0x0000003371c2235d in signal_emit_unlocked_R (node=node@entry=0xcf5780, detail=detail@entry=0, instance=instance@entry=0xcf78a0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff8b1d4520) at gsignal.c:3586 #22 0x0000003371c2a0f2 in g_signal_emit_valist (instance=instance@entry=0xcf78a0, signal_id=signal_id@entry=2, detail=detail@entry=0, var_args=var_args@entry=0x7fff8b1d4778) at gsignal.c:3330 #23 0x0000003371c2a8f8 in g_signal_emit_by_name (instance=instance@entry=0xcf78a0, detailed_signal=detailed_signal@entry=0x4b183d "link-changed") at gsignal.c:3426 #24 0x000000000044c6f3 in announce_object (platform=platform@entry=0xcf78a0, object=0xde1720, change_type=change_type@entry=NM_PLATFORM_SIGNAL_REMOVED, reason=reason@entry=NM_PLATFORM_REASON_EXTERNAL) at platform/nm-linux-platform.c:1572 #25 0x000000000044ec07 in event_notification (msg=<optimized out>, user_data=<optimized out>) at platform/nm-linux-platform.c:1886 #26 0x0000003844c1117f in nl_cb_call (msg=<optimized out>, type=<optimized out>, cb=<optimized out>) at ../include/netlink-private/netlink.h:141 #27 recvmsgs (cb=0xcf7240, sk=0xcf7330) at nl.c:952 #28 nl_recvmsgs_report (sk=0xcf7330, cb=0xcf7240) at nl.c:1003 #29 0x0000003844c11549 in nl_recvmsgs (sk=<optimized out>, cb=<optimized out>) at nl.c:1027 #30 0x0000003844c11569 in nl_recvmsgs_default (sk=<optimized out>) at nl.c:1041 #31 0x000000000044e955 in event_handler (channel=<optimized out>, io_condition=<optimized out>, user_data=0xcf78a0) at platform/nm-linux-platform.c:3804 #32 0x0000003370c492a6 in g_main_dispatch (context=0xcf5190) at gmain.c:3066 #33 g_main_context_dispatch (context=context@entry=0xcf5190) at gmain.c:3642 #34 0x0000003370c49628 in g_main_context_iterate (context=0xcf5190, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #35 0x0000003370c49a3a in g_main_loop_run (loop=0xcf4e30) at gmain.c:3907 #36 0x0000000000429f15 in main (argc=1, argv=0x7fff8b1d4f38) at main.c:678 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-23 11:18:45 +02:00
* @reason: the state change reason for the @slave
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* If @self is capable of enslaving other devices (ie it's a bridge, bond, team,
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
* etc) then this function releases the previously enslaved @slave and/or
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* updates the state of @self and @slave to reflect its release.
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
*/
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
static void
device/trivial: rename master related function of nm-device We have the master/slave related functions - for master device: - nm_device_master_add_slave() - nm_device_master_release_slaves() - nm_device_release_one_slave() - nm_device_enslave_slave() - for slave device: - nm_device_slave_notify_enslave() - nm_device_slave_notify_release() Rename the two that didn't match the pattern to - nm_device_master_release_one_slave() - nm_device_master_enslave_slave()
2015-08-06 14:37:12 +02:00
nm_device_master_release_one_slave (NMDevice *self, NMDevice *slave, gboolean configure, NMDeviceStateReason reason)
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
{
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
NMDevicePrivate *priv;
NMDevicePrivate *slave_priv;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
SlaveInfo *info;
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
gs_unref_object NMDevice *self_free = NULL;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
g_return_if_fail (NM_DEVICE (self));
g_return_if_fail (NM_DEVICE (slave));
g_return_if_fail (NM_DEVICE_GET_CLASS (self)->release_slave != NULL);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
info = find_slave_info (self, slave);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
_LOGT (LOGD_CORE, "master: release one slave %p/%s%s", slave, nm_device_get_iface (slave),
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
!info ? " (not registered)" : "");
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
if (!info)
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
g_return_if_reached ();
priv = NM_DEVICE_GET_PRIVATE (self);
slave_priv = NM_DEVICE_GET_PRIVATE (slave);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
g_return_if_fail (self == slave_priv->master);
nm_assert (slave == info->slave);
/* first, let subclasses handle the release ... */
device: don't return error from release_slave() release_slave() should do the right thing and handle errors as good as it can. There is no value in propagating the error and it's not clear what the caller should do in face of a failure during release.
2015-12-02 09:56:17 +01:00
if (info->slave_is_enslaved)
NM_DEVICE_GET_CLASS (self)->release_slave (self, slave, configure);
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
/* raise notifications about the release, including clearing is_enslaved. */
nm_device_slave_notify_release (slave, reason);
/* keep both alive until the end of the function.
* Transfers ownership from slave_priv->master. */
self_free = self;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
c_list_unlink_init (&info->lst_slave);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
slave_priv->master = NULL;
g_signal_handler_disconnect (slave, info->watch_id);
g_object_unref (slave);
g_slice_free (SlaveInfo, info);
core: update hardware address when slaves change The hardware address of a device often changes when slaves change, for example with bond interfaces, which take the hardware address of their first slave. Make sure that's always up-to-date.
2013-01-18 14:34:40 -06:00
core: add NMActivationStateFlags "master-has-slaves"
2017-09-27 10:16:15 +02:00
if (c_list_is_empty (&priv->slaves)) {
_active_connection_set_state_flags_full (self,
0,
NM_ACTIVATION_STATE_FLAG_MASTER_HAS_SLAVES);
}
core: update hardware address when slaves change The hardware address of a device often changes when slaves change, for example with bond interfaces, which take the hardware address of their first slave. Make sure that's always up-to-date.
2013-01-18 14:34:40 -06:00
/* Ensure the device's hardware address is up-to-date; it often changes
* when slaves change.
*/
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_update_hw_address (self);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_by_flags (slave, NM_UNMANAGED_IS_SLAVE, NM_UNMAN_FLAG_OP_FORGET, NM_DEVICE_STATE_REASON_REMOVED);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
}
device: move the decision whether to wait for IFF_UP a virtual function We'd like to override it for veths.
2015-04-07 14:24:12 +02:00
/**
* can_unmanaged_external_down:
* @self: the device
*
* Check whether the device should stay NM_UNMANAGED_EXTERNAL_DOWN unless
* IFF_UP-ed externally.
*/
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
static gboolean
device: move the decision whether to wait for IFF_UP a virtual function We'd like to override it for veths.
2015-04-07 14:24:12 +02:00
can_unmanaged_external_down (NMDevice *self)
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
{
device: rename priv->is_nm_owned to priv->nm_owned Only a matter of taste, but nm_device_get_is_nm_owned() sounds strange.
2017-05-31 16:42:05 +02:00
return !NM_DEVICE_GET_PRIVATE (self)->nm_owned
device: trival refactoring in can_unmanaged_external_down() Swap order of operands so that the "cheaper" is evaluated first.
2016-03-23 09:49:39 +01:00
&& nm_device_is_software (self);
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
}
device: refactor setting unmanaged flag EXTERNAL_DOWN This should not actually change how we handle EXTERNAL_DOWN unmanaged devices.
2016-03-21 14:56:15 +01:00
static NMUnmanFlagOp
is_unmanaged_external_down (NMDevice *self, gboolean consider_can)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if ( consider_can
&& !NM_DEVICE_GET_CLASS (self)->can_unmanaged_external_down (self))
return NM_UNMAN_FLAG_OP_FORGET;
/* Manage externally-created software interfaces only when they are IFF_UP */
if ( priv->ifindex <= 0
device: consider external devices as unmanaged until they have an IP address
2016-03-21 15:30:07 +01:00
|| !priv->up
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
|| !( !c_list_is_empty (&priv->slaves)
|| nm_platform_link_can_assume (nm_device_get_platform (self), priv->ifindex)))
device: refactor setting unmanaged flag EXTERNAL_DOWN This should not actually change how we handle EXTERNAL_DOWN unmanaged devices.
2016-03-21 14:56:15 +01:00
return NM_UNMAN_FLAG_OP_SET_UNMANAGED;
return NM_UNMAN_FLAG_OP_SET_MANAGED;
}
device: refactor by adding set_unmanaged_external_down() function No functional change.
2016-03-24 14:15:49 +01:00
static void
device: consider external devices as unmanaged until they have an IP address
2016-03-21 15:30:07 +01:00
set_unmanaged_external_down (NMDevice *self, gboolean only_if_unmanaged)
device: refactor by adding set_unmanaged_external_down() function No functional change.
2016-03-24 14:15:49 +01:00
{
NMUnmanFlagOp ext_flags;
if (!nm_device_get_unmanaged_mask (self, NM_UNMANAGED_EXTERNAL_DOWN))
return;
device: consider external devices as unmanaged until they have an IP address
2016-03-21 15:30:07 +01:00
if (only_if_unmanaged) {
if (!nm_device_get_unmanaged_flags (self, NM_UNMANAGED_EXTERNAL_DOWN))
return;
}
device: refactor by adding set_unmanaged_external_down() function No functional change.
2016-03-24 14:15:49 +01:00
ext_flags = is_unmanaged_external_down (self, FALSE);
if (ext_flags != NM_UNMAN_FLAG_OP_SET_UNMANAGED) {
/* Ensure the assume check is queued before any queued state changes
* from the transition to UNAVAILABLE.
*/
nm_device_queue_recheck_assume (self);
}
nm_device_set_unmanaged_by_flags (self,
NM_UNMANAGED_EXTERNAL_DOWN,
ext_flags,
NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
}
device: renew dhcp leases on awake for software devices This makes sure that devices like bond get their dhcp renewed [thaller@redhat.com: original patch modified to rename now-public function update_dynamic_ip_setup()] https://bugzilla.gnome.org/show_bug.cgi?id=764398
2016-03-26 01:26:36 -04:00
void
nm_device_update_dynamic_ip_setup (NMDevice *self)
device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368) When carrier appears (e.g. the plug was re-inserted) we re-new addresses, because the network could change. https://bugzilla.gnome.org/show_bug.cgi?id=743368
2015-06-25 14:50:23 +00:00
{
device: renew dhcp leases on awake for software devices This makes sure that devices like bond get their dhcp renewed [thaller@redhat.com: original patch modified to rename now-public function update_dynamic_ip_setup()] https://bugzilla.gnome.org/show_bug.cgi?id=764398
2016-03-26 01:26:36 -04:00
NMDevicePrivate *priv;
lldp: fix crash in nm_device_update_dynamic_ip_setup() due to uninitialized @error Fixes: 07a9364d9c151bc3086a863759d31d0857ae011e
2016-04-25 12:06:40 +02:00
GError *error = NULL;
lldp: decouple NMLldpListener from platform Make NMLldpListener independent from platform code so that it can be tested more easily.
2015-11-10 14:17:42 +01:00
gconstpointer addr;
size_t addr_length;
device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368) When carrier appears (e.g. the plug was re-inserted) we re-new addresses, because the network could change. https://bugzilla.gnome.org/show_bug.cgi?id=743368
2015-06-25 14:50:23 +00:00
device: renew dhcp leases on awake for software devices This makes sure that devices like bond get their dhcp renewed [thaller@redhat.com: original patch modified to rename now-public function update_dynamic_ip_setup()] https://bugzilla.gnome.org/show_bug.cgi?id=764398
2016-03-26 01:26:36 -04:00
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368) When carrier appears (e.g. the plug was re-inserted) we re-new addresses, because the network could change. https://bugzilla.gnome.org/show_bug.cgi?id=743368
2015-06-25 14:50:23 +00:00
g_hash_table_remove_all (priv->ip6_saved_properties);
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
if (priv->dhcp4.client) {
device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368) When carrier appears (e.g. the plug was re-inserted) we re-new addresses, because the network could change. https://bugzilla.gnome.org/show_bug.cgi?id=743368
2015-06-25 14:50:23 +00:00
if (!nm_device_dhcp4_renew (self, FALSE)) {
nm_device_state_changed (self,
NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_DHCP_FAILED);
return;
}
}
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
if (priv->dhcp6.client) {
device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368) When carrier appears (e.g. the plug was re-inserted) we re-new addresses, because the network could change. https://bugzilla.gnome.org/show_bug.cgi?id=743368
2015-06-25 14:50:23 +00:00
if (!nm_device_dhcp6_renew (self, FALSE)) {
nm_device_state_changed (self,
NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_DHCP_FAILED);
return;
}
}
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (priv->ndisc) {
device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368) When carrier appears (e.g. the plug was re-inserted) we re-new addresses, because the network could change. https://bugzilla.gnome.org/show_bug.cgi?id=743368
2015-06-25 14:50:23 +00:00
/* FIXME: todo */
}
if (priv->dnsmasq_manager) {
/* FIXME: todo */
}
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
if (priv->lldp_listener && nm_lldp_listener_is_running (priv->lldp_listener)) {
nm_lldp_listener_stop (priv->lldp_listener);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
addr = nm_platform_link_get_address (nm_device_get_platform (self), priv->ifindex, &addr_length);
lldp: decouple NMLldpListener from platform Make NMLldpListener independent from platform code so that it can be tested more easily.
2015-11-10 14:17:42 +01:00
systemd: merge branch systemd into th/systemd-lldp-bgo763384 As the lldp API changed, adjust "nm-lldp-listener.c". Note that the commit is not yet functional due to missing sd_event_source_set_enabled() and sd_event_source_set_time().
2016-02-29 14:30:15 +01:00
if (!nm_lldp_listener_start (priv->lldp_listener, nm_device_get_ifindex (self), &error)) {
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
_LOGD (LOGD_DEVICE, "LLDP listener %p could not be restarted: %s",
priv->lldp_listener, error->message);
g_clear_error (&error);
}
}
device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368) When carrier appears (e.g. the plug was re-inserted) we re-new addresses, because the network could change. https://bugzilla.gnome.org/show_bug.cgi?id=743368
2015-06-25 14:50:23 +00:00
}
device/trivial: rename functions related to "carrier"
2017-05-12 16:21:55 +02:00
/*****************************************************************************/
device: don't call virtual function carrier_changed() directly Don't give the subclass the ability to override the parents behavior. The parent implementation is not intended to allow for that. Instead, restrict the flexibility of how the virtual function integrates with the larger picture. That means, the virtual function is only called at one place, and there is only one implementation in NMDeviceEthernet (and it doesn't really matter whether the implementation chains up the parent implementation or not).
2017-05-12 16:17:18 +02:00
static void
carrier_changed_notify (NMDevice *self, gboolean carrier)
{
/* stub */
}
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
carrier_changed (NMDevice *self, gboolean carrier)
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
device: fix check on device state in carrier_changed() The function can now be called on unrealized devices before the initial unmanaged flags are set and for those devices nm_device_get_managed() will return TRUE. Since we only accept states > UNMANAGED, return early when the condition is not met. Fixes the following failed assertion: carrier_changed: assertion 'priv->state >= NM_DEVICE_STATE_UNAVAILABLE' failed https://bugzilla.gnome.org/show_bug.cgi?id=760844
2016-01-19 21:20:46 +01:00
if (priv->state <= NM_DEVICE_STATE_UNMANAGED)
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
return;
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_recheck_available_connections (self);
core: rework ignore-carrier device behavior Previously, ignore-carrier devices were always in the unavailable state until they were activated. This required some complicated code to keep track of whether the device was available or not based on what connections existed, whether those connections were static-IP, and whether the device was ignore-carrier. Various bits of the code used nm_device_can_activate() for two different purposes: (1) to determine if the device was available on an L2 basis, which nm_device_can_activate() wasn't well-suited to, and (2) whether a specific connection could be activated at a given time based on ignore-carrier and whether the connection was static IP or not. Remove that complexity and confusion by making ignore-carrier devices always move to DISCONNECTED state, and simply refuse to activate connections that require connectivity, but allow connections that don't require connectivity. Also, when the device has no carrier, don't add connections that require connectivity to the AvailableConnections device property.
2013-11-04 19:51:28 -06:00
core: fix bug with ignore-carrier and master/slave devices (rh #1083521) Even ignore-carrier devices need to be aware of carrier-up events so they can continue DHCP when the link comes up. They just ignore all carrier-down events.
2014-04-02 09:15:54 -05:00
/* ignore-carrier devices ignore all carrier-down events */
if (priv->ignore_carrier && !carrier)
return;
core: change the rules for ignore-carrier The previous ignore-carrier rules did not work well with dynamic IP (dhcp/slaac) connections. Change the rule so that only static IP connections can be activated when carrier is not present (but both static and dynamic connections will remain up when carrier is lost).
2013-07-12 10:43:45 -04:00
device: transform NM_DEVICE_IS_MASTER gobject property to field in NMDeviceClass We don't need this flexibility of having a full fledged GObject property for is-master. The property value only depends on the device's class.
2017-06-01 23:08:30 +02:00
if (nm_device_is_master (self)) {
device: handle carrier changes for master device differently For master devices, instead of ignoring loss of carrier entirely, handle it. First of all, master devices are now by default ignore-carrier=yes. That means, without explict user configuration in NetworkManager.conf, the previous behavior in carrier_changed() does not change. If the user decides to configure the master device like [device-with-carrier] match-device=type:bond,type:bridge,type:team ignore-carrier=no then, master device will disconnect on carrier loss like regular devices. https://github.com/NetworkManager/NetworkManager/pull/18 Co-authored-by: Thomas Haller <thaller@redhat.com>
2017-06-01 23:57:03 +02:00
if (carrier) {
/* Force master to retry getting ip addresses when carrier
* is restored. */
if (priv->state == NM_DEVICE_STATE_ACTIVATED)
nm_device_update_dynamic_ip_setup (self);
else {
if (nm_device_activate_ip4_state_in_wait (self))
nm_device_activate_stage3_ip4_start (self);
if (nm_device_activate_ip6_state_in_wait (self))
nm_device_activate_stage3_ip6_start (self);
}
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
return;
device: renew IP addressing on carrier change also for master devices Commit 348452f1e06e9bde9f84b90db4f5620ee672389a (device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368)) added this behavior for non-master devices. The same reasoning applies here too. https://github.com/NetworkManager/NetworkManager/pull/18 Based-on-patch-by: Nikolay Martynov <mar.kolya@gmail.com>
2017-06-02 11:11:50 +02:00
}
device: handle carrier changes for master device differently For master devices, instead of ignoring loss of carrier entirely, handle it. First of all, master devices are now by default ignore-carrier=yes. That means, without explict user configuration in NetworkManager.conf, the previous behavior in carrier_changed() does not change. If the user decides to configure the master device like [device-with-carrier] match-device=type:bond,type:bridge,type:team ignore-carrier=no then, master device will disconnect on carrier loss like regular devices. https://github.com/NetworkManager/NetworkManager/pull/18 Co-authored-by: Thomas Haller <thaller@redhat.com>
2017-06-01 23:57:03 +02:00
/* fall-through and change state of device */
device: remove function nm_device_is_enslaved() There were only two callers. Let them access the field directly.
2017-05-14 09:45:53 +02:00
} else if (priv->is_enslaved && !carrier) {
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
/* Slaves don't deactivate when they lose carrier; for
* bonds/teams in particular that would be actively
* counterproductive.
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
*/
return;
}
if (carrier) {
if (priv->state == NM_DEVICE_STATE_UNAVAILABLE) {
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_queue_state (self, NM_DEVICE_STATE_DISCONNECTED,
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
NM_DEVICE_STATE_REASON_CARRIER);
core: fix auto-activation of ignore-carrier devices when carrier appears (rh #1076592) If a device had its carrier ignored, and did not have a carrier on startup, then NetworkManager would not re-check autoconnect connections when the device's carrier appeared. Because ignore-carrier devices are always in DISCONNECTED state when they are managed, the nm-device.c::carrier_changed() code essentially did nothing when the carrier appeared. It needs to also trigger an auto-activation recheck signal when the carrier appears to ensure that now-valid connections (like those that require DHCP or IPv6) can be auto-activated.
2014-03-14 15:21:14 -05:00
} else if (priv->state == NM_DEVICE_STATE_DISCONNECTED) {
/* If the device is already in DISCONNECTED state without a carrier
* (probably because it is tagged for carrier ignore) ensure that
* when the carrier appears, auto connections are rechecked for
* the device.
*/
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_emit_recheck_auto_activate (self);
device: renew DHCP lease for active "ignore-carrier" devices on carrier-on (bgo #743368) When carrier appears (e.g. the plug was re-inserted) we re-new addresses, because the network could change. https://bugzilla.gnome.org/show_bug.cgi?id=743368
2015-06-25 14:50:23 +00:00
} else if (priv->state == NM_DEVICE_STATE_ACTIVATED) {
/* If the device is active without a carrier (probably because it is
* tagged for carrier ignore) ensure that when the carrier appears we
* renew DHCP leases and such.
*/
device: renew dhcp leases on awake for software devices This makes sure that devices like bond get their dhcp renewed [thaller@redhat.com: original patch modified to rename now-public function update_dynamic_ip_setup()] https://bugzilla.gnome.org/show_bug.cgi?id=764398
2016-03-26 01:26:36 -04:00
nm_device_update_dynamic_ip_setup (self);
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
}
} else {
if (priv->state == NM_DEVICE_STATE_UNAVAILABLE) {
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
if ( priv->queued_state.id
&& priv->queued_state.state >= NM_DEVICE_STATE_DISCONNECTED)
queued_state_clear (self);
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
} else {
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_queue_state (self, NM_DEVICE_STATE_UNAVAILABLE,
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
NM_DEVICE_STATE_REASON_CARRIER);
}
}
}
#define LINK_DISCONNECT_DELAY 4
static gboolean
device/trivial: rename functions related to "carrier"
2017-05-12 16:21:55 +02:00
carrier_disconnected_action_cb (gpointer user_data)
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
device: prefix log messages related to carrier It's easier to search in the logfile.
2017-06-02 16:47:10 +02:00
_LOGD (LOGD_DEVICE, "carrier: link disconnected (calling deferred action) (id=%u)", priv->carrier_defer_id);
core: add debug logging for link disconnect action Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-06 15:09:57 +01:00
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
priv->carrier_defer_id = 0;
device: don't call virtual function carrier_changed() directly Don't give the subclass the ability to override the parents behavior. The parent implementation is not intended to allow for that. Instead, restrict the flexibility of how the virtual function integrates with the larger picture. That means, the virtual function is only called at one place, and there is only one implementation in NMDeviceEthernet (and it doesn't really matter whether the implementation chains up the parent implementation or not).
2017-05-12 16:17:18 +02:00
carrier_changed (self, FALSE);
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
return FALSE;
}
core: add debug logging for link disconnect action Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-06 15:09:57 +01:00
static void
device/trivial: rename functions related to "carrier"
2017-05-12 16:21:55 +02:00
carrier_disconnected_action_cancel (NMDevice *self)
core: add debug logging for link disconnect action Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-06 15:09:57 +01:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: minor cleanup of carrier_disconnected_action_cancel()
2017-05-12 16:22:47 +02:00
guint id = priv->carrier_defer_id;
core: add debug logging for link disconnect action Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-06 15:09:57 +01:00
device: minor cleanup of carrier_disconnected_action_cancel()
2017-05-12 16:22:47 +02:00
if (nm_clear_g_source (&priv->carrier_defer_id)) {
device: prefix log messages related to carrier It's easier to search in the logfile.
2017-06-02 16:47:10 +02:00
_LOGD (LOGD_DEVICE, "carrier: link disconnected (canceling deferred action) (id=%u)",
device: minor cleanup of carrier_disconnected_action_cancel()
2017-05-12 16:22:47 +02:00
id);
core: add debug logging for link disconnect action Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-06 15:09:57 +01:00
}
}
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_set_carrier (NMDevice *self, gboolean carrier)
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMDeviceState state = nm_device_get_state (self);
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
if (priv->carrier == carrier)
return;
priv->carrier = carrier;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_CARRIER);
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
if (priv->carrier) {
device: prefix log messages related to carrier It's easier to search in the logfile.
2017-06-02 16:47:10 +02:00
_LOGI (LOGD_DEVICE, "carrier: link connected");
device/trivial: rename functions related to "carrier"
2017-05-12 16:21:55 +02:00
carrier_disconnected_action_cancel (self);
device: move carrier_changed_notify() notification to nm_device_set_carrier() Note that: - carrier_changed_notify() has only one implementation: NMDeviceEthernet to call get_link_speed() when carrier comes back. - currently, calling carrier_changed_notify() with carrier=FALSE has no effect, because NMDeviceEthernet only acts on carrier=TRUE. - when carrier appears, nm_device_set_carrier() will call carrier_changed() right away. We only call carrier_changed() with carrier=TRUE only at one place. The change merley moves carrier_changed_notify() out of the function. Apart from that it has no effect. - when carrier disappears, previoulsy we would delay action for 4 seconds. Hence, we would delay carrier_changed_notify() as well -- although it has no effect. The last point is at least ugly. Fix it by moving carrier_changed_notify() to nm_device_set_carrier().
2017-06-02 16:09:55 +02:00
NM_DEVICE_GET_CLASS (self)->carrier_changed_notify (self, carrier);
device: don't call virtual function carrier_changed() directly Don't give the subclass the ability to override the parents behavior. The parent implementation is not intended to allow for that. Instead, restrict the flexibility of how the virtual function integrates with the larger picture. That means, the virtual function is only called at one place, and there is only one implementation in NMDeviceEthernet (and it doesn't really matter whether the implementation chains up the parent implementation or not).
2017-05-12 16:17:18 +02:00
carrier_changed (self, TRUE);
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
if (priv->carrier_wait_id) {
nm_device_remove_pending_action (self, NM_PENDING_ACTION_CARRIER_WAIT, FALSE);
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
_carrier_wait_check_queued_act_request (self);
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
}
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
} else {
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
if (priv->carrier_wait_id)
nm_device_add_pending_action (self, NM_PENDING_ACTION_CARRIER_WAIT, FALSE);
device: move carrier_changed_notify() notification to nm_device_set_carrier() Note that: - carrier_changed_notify() has only one implementation: NMDeviceEthernet to call get_link_speed() when carrier comes back. - currently, calling carrier_changed_notify() with carrier=FALSE has no effect, because NMDeviceEthernet only acts on carrier=TRUE. - when carrier appears, nm_device_set_carrier() will call carrier_changed() right away. We only call carrier_changed() with carrier=TRUE only at one place. The change merley moves carrier_changed_notify() out of the function. Apart from that it has no effect. - when carrier disappears, previoulsy we would delay action for 4 seconds. Hence, we would delay carrier_changed_notify() as well -- although it has no effect. The last point is at least ugly. Fix it by moving carrier_changed_notify() to nm_device_set_carrier().
2017-06-02 16:09:55 +02:00
NM_DEVICE_GET_CLASS (self)->carrier_changed_notify (self, carrier);
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
if ( state <= NM_DEVICE_STATE_DISCONNECTED
&& !priv->queued_act_request) {
device: prefix log messages related to carrier It's easier to search in the logfile.
2017-06-02 16:47:10 +02:00
_LOGD (LOGD_DEVICE, "carrier: link disconnected");
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
carrier_changed (self, FALSE);
} else {
priv->carrier_defer_id = g_timeout_add_seconds (LINK_DISCONNECT_DELAY,
carrier_disconnected_action_cb, self);
device: prefix log messages related to carrier It's easier to search in the logfile.
2017-06-02 16:47:10 +02:00
_LOGD (LOGD_DEVICE, "carrier: link disconnected (deferring action for %d seconds) (id=%u)",
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
LINK_DISCONNECT_DELAY, priv->carrier_defer_id);
}
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
}
}
device: rename and minor refactoring of check_carrier() The name should mirror what we already have: nm_device_set_carrier(). Also, move the code closer to nm_device_set_carrier() and refactor it a bit.
2017-05-14 22:08:26 +02:00
static void
nm_device_set_carrier_from_platform (NMDevice *self)
{
device: cleanup nm_device_set_carrier_from_platform() nm_device_set_carrier_from_platform() is only called from two places. - both check for NM_DEVICE_CAP_CARRIER_DETECT, so move that check inside the function. - drop the logging in realize_start_setup(). nm_device_set_carrier() already does logging. - always set the fake carrier in nm_device_set_carrier_from_platform(). For the fake carrer, we anyway expect it to be already TRUE in most case, so usually this should have no effect. Also emit a property changed signal. That is necessary to refresh the D-Bus property.
2017-05-15 11:35:41 +02:00
if (nm_device_has_capability (self, NM_DEVICE_CAP_CARRIER_DETECT)) {
if (!nm_device_has_capability (self, NM_DEVICE_CAP_NONSTANDARD_CARRIER)) {
nm_device_set_carrier (self,
nm_platform_link_is_connected (nm_device_get_platform (self),
nm_device_get_ip_ifindex (self)));
}
} else {
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
/* Fake online link when carrier detection is not available. */
if (!priv->carrier) {
priv->carrier = TRUE;
_notify (self, PROP_CARRIER);
}
device: rename and minor refactoring of check_carrier() The name should mirror what we already have: nm_device_set_carrier(). Also, move the code closer to nm_device_set_carrier() and refactor it a bit.
2017-05-14 22:08:26 +02:00
}
}
device/trivial: rename functions related to "carrier"
2017-05-12 16:21:55 +02:00
/*****************************************************************************/
device: set the master on device addition Otherwise we won't notice the device is a slave on NM startup until someone changes the link or tries to activate the device.
2014-12-05 13:12:55 +01:00
static void
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
device_recheck_slave_status (NMDevice *self, const NMPlatformLink *plink)
device: set the master on device addition Otherwise we won't notice the device is a slave on NM startup until someone changes the link or tries to activate the device.
2014-12-05 13:12:55 +01:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: ignore enslavement to ovs-master That one is special. All interfaces that are attached to OpenVSwitch ports appear as slaves to that one even for our purposes we like to pretend they're slaves to the actual OpenVSwitch bridges.
2017-08-24 09:09:18 +02:00
NMDevice *master;
nm_auto_nmpobj const NMPObject *plink_master_keep_alive = NULL;
const NMPlatformLink *plink_master;
device: set the master on device addition Otherwise we won't notice the device is a slave on NM startup until someone changes the link or tries to activate the device.
2014-12-05 13:12:55 +01:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
g_return_if_fail (plink);
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
device: don't remove the device from master if its link has no master We only need to do that when we're replacing the master with a different one. Just after the link creation is has no master and we'd remove it from the master device here.
2015-12-16 18:51:58 +01:00
if (plink->master <= 0)
return;
device: ignore enslavement to ovs-master That one is special. All interfaces that are attached to OpenVSwitch ports appear as slaves to that one even for our purposes we like to pretend they're slaves to the actual OpenVSwitch bridges.
2017-08-24 09:09:18 +02:00
master = nm_manager_get_device_by_ifindex (nm_manager_get (), plink->master);
plink_master = nm_platform_link_get (nm_device_get_platform (self), plink->master);
plink_master_keep_alive = nmp_object_ref (NMP_OBJECT_UP_CAST (plink_master));
if ( master == NULL
&& plink_master
&& g_strcmp0 (plink_master->name, "ovs-system") == 0
&& plink_master->type == NM_LINK_TYPE_OPENVSWITCH) {
_LOGD (LOGD_DEVICE, "the device claimed by openvswitch");
return;
}
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
if (priv->master) {
if ( plink->master > 0
&& plink->master == nm_device_get_ifindex (priv->master)) {
/* call add-slave again. We expect @self already to be added to
* the master, but this also triggers a recheck-assume. */
nm_device_master_add_slave (priv->master, self, FALSE);
return;
}
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
nm_device_master_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
}
device: ignore enslavement to ovs-master That one is special. All interfaces that are attached to OpenVSwitch ports appear as slaves to that one even for our purposes we like to pretend they're slaves to the actual OpenVSwitch bridges.
2017-08-24 09:09:18 +02:00
if (master && NM_DEVICE_GET_CLASS (master)->enslave_slave)
nm_device_master_add_slave (master, self, FALSE);
else if (master) {
_LOGI (LOGD_DEVICE, "enslaved to non-master-type device %s; ignoring",
nm_device_get_iface (master));
} else {
_LOGW (LOGD_DEVICE, "enslaved to unknown device %d (%s%s%s)",
plink->master,
NM_PRINT_FMT_QUOTED (plink_master, "\"", plink_master->name, "\"", "??"));
device: set the master on device addition Otherwise we won't notice the device is a slave on NM startup until someone changes the link or tries to activate the device.
2014-12-05 13:12:55 +01:00
}
}
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
static void
ndisc_set_router_config (NMNDisc *ndisc, NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: refactor ndisc_set_router_config() - only record @now timestamp if we actually need it. - use gint32 for @now. It seems wrong that NMNDiscDNSServer uses guint32 for the timestamp. We keep nm_utils_get_monotonic_timestamp_s() as gint32 for a reason. - ensure the arrays are initialized to zero. E.g. ndisc_addr->dad_counter was uninitalized. - set the size for arrays outside the loop - use g_array_unref(). I think that is usually better. It makes only a difference when somebody else holds a reference to the array. And in that case, it usually seems better not to clear the array, just release your refrence.
2016-11-10 08:53:17 +01:00
gint32 now;
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
GArray *addresses, *dns_servers, *dns_domains;
guint len, i;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
const NMDedupMultiHeadEntry *head_entry;
NMDedupMultiIter ipconf_iter;
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
if (nm_ndisc_get_node_type (ndisc) != NM_NDISC_NODE_TYPE_ROUTER)
return;
device: refactor ndisc_set_router_config() - only record @now timestamp if we actually need it. - use gint32 for @now. It seems wrong that NMNDiscDNSServer uses guint32 for the timestamp. We keep nm_utils_get_monotonic_timestamp_s() as gint32 for a reason. - ensure the arrays are initialized to zero. E.g. ndisc_addr->dad_counter was uninitalized. - set the size for arrays outside the loop - use g_array_unref(). I think that is usually better. It makes only a difference when somebody else holds a reference to the array. And in that case, it usually seems better not to clear the array, just release your refrence.
2016-11-10 08:53:17 +01:00
now = nm_utils_get_monotonic_timestamp_s ();
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
head_entry = nm_ip6_config_lookup_addresses (priv->ip6_config);
addresses = g_array_sized_new (FALSE, TRUE, sizeof (NMNDiscAddress),
head_entry ? head_entry->len : 0);
nm_dedup_multi_iter_for_each (&ipconf_iter, head_entry) {
const NMPlatformIP6Address *addr = NMP_OBJECT_CAST_IP6_ADDRESS (ipconf_iter.current->obj);
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
NMNDiscAddress *ndisc_addr;
if (IN6_IS_ADDR_LINKLOCAL (&addr->address))
continue;
if ( addr->n_ifa_flags & IFA_F_TENTATIVE
|| addr->n_ifa_flags & IFA_F_DADFAILED)
continue;
if (addr->plen != 64)
continue;
device: properly size the arrays
2016-11-10 08:10:28 +01:00
g_array_set_size (addresses, addresses->len+1);
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
ndisc_addr = &g_array_index (addresses, NMNDiscAddress, addresses->len-1);
ndisc_addr->address = addr->address;
ndisc_addr->timestamp = addr->timestamp;
ndisc_addr->lifetime = addr->lifetime;
ndisc_addr->preferred = addr->preferred;
}
len = nm_ip6_config_get_num_nameservers (priv->ip6_config);
device: refactor ndisc_set_router_config() - only record @now timestamp if we actually need it. - use gint32 for @now. It seems wrong that NMNDiscDNSServer uses guint32 for the timestamp. We keep nm_utils_get_monotonic_timestamp_s() as gint32 for a reason. - ensure the arrays are initialized to zero. E.g. ndisc_addr->dad_counter was uninitalized. - set the size for arrays outside the loop - use g_array_unref(). I think that is usually better. It makes only a difference when somebody else holds a reference to the array. And in that case, it usually seems better not to clear the array, just release your refrence.
2016-11-10 08:53:17 +01:00
dns_servers = g_array_sized_new (FALSE, TRUE, sizeof (NMNDiscDNSServer), len);
g_array_set_size (dns_servers, len);
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
for (i = 0; i < len; i++) {
const struct in6_addr *nameserver = nm_ip6_config_get_nameserver (priv->ip6_config, i);
NMNDiscDNSServer *ndisc_nameserver;
device: fix array indexing in ndisc_set_router_config() Fixes: de52c25cfd6b452e7529ec222c5d8eacd2466aab
2016-11-10 10:03:59 +01:00
ndisc_nameserver = &g_array_index (dns_servers, NMNDiscDNSServer, i);
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
ndisc_nameserver->address = *nameserver;
ndisc_nameserver->timestamp = now;
ndisc_nameserver->lifetime = NM_NDISC_ROUTER_LIFETIME;
}
len = nm_ip6_config_get_num_searches (priv->ip6_config);
device: refactor ndisc_set_router_config() - only record @now timestamp if we actually need it. - use gint32 for @now. It seems wrong that NMNDiscDNSServer uses guint32 for the timestamp. We keep nm_utils_get_monotonic_timestamp_s() as gint32 for a reason. - ensure the arrays are initialized to zero. E.g. ndisc_addr->dad_counter was uninitalized. - set the size for arrays outside the loop - use g_array_unref(). I think that is usually better. It makes only a difference when somebody else holds a reference to the array. And in that case, it usually seems better not to clear the array, just release your refrence.
2016-11-10 08:53:17 +01:00
dns_domains = g_array_sized_new (FALSE, TRUE, sizeof (NMNDiscDNSDomain), len);
g_array_set_size (dns_domains, len);
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
for (i = 0; i < len; i++) {
const char *search = nm_ip6_config_get_search (priv->ip6_config, i);
NMNDiscDNSDomain *ndisc_search;
device: fix array indexing in ndisc_set_router_config() Fixes: de52c25cfd6b452e7529ec222c5d8eacd2466aab
2016-11-10 10:03:59 +01:00
ndisc_search = &g_array_index (dns_domains, NMNDiscDNSDomain, i);
device: fix memleak for ndisc_search->domain in ndisc_set_router_config() It is a bit fragile not to clone the string because we depend on nm_ip6_config_get_search(priv->ip6_config) to be stable. In practice, it's no problem. Saves an additional strdup and the effort to cleanup the memory afterwards.
2016-11-10 10:03:59 +01:00
ndisc_search->domain = (char *) search;
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
ndisc_search->timestamp = now;
ndisc_search->lifetime = NM_NDISC_ROUTER_LIFETIME;
}
nm_ndisc_set_config (ndisc, addresses, dns_servers, dns_domains);
device: refactor ndisc_set_router_config() - only record @now timestamp if we actually need it. - use gint32 for @now. It seems wrong that NMNDiscDNSServer uses guint32 for the timestamp. We keep nm_utils_get_monotonic_timestamp_s() as gint32 for a reason. - ensure the arrays are initialized to zero. E.g. ndisc_addr->dad_counter was uninitalized. - set the size for arrays outside the loop - use g_array_unref(). I think that is usually better. It makes only a difference when somebody else holds a reference to the array. And in that case, it usually seems better not to clear the array, just release your refrence.
2016-11-10 08:53:17 +01:00
g_array_unref (addresses);
g_array_unref (dns_servers);
g_array_unref (dns_domains);
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
}
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
static gboolean
device_link_changed (NMDevice *self)
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDeviceClass *klass = NM_DEVICE_GET_CLASS (self);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
gboolean ip_ifname_changed = FALSE;
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
nm_auto_nmpobj const NMPObject *pllink_keep_alive = NULL;
platform: refactor virtual methods for link objects in NMPlatform Change nm_platform_link_get() to return the cached NMPlatformLink instance. Now what all our implementations (fake and linux) have such a cache internal object, let's just expose it directly. Note that the lifetime of the exposed link object is possibly quite short. A caller must copy the returned value if he intends to preserve it for later. Also add nm_platform_link_get_by_ifname() and modify nm_platform_link_get_by_address() to return the instance. Certain functions, such as nm_platform_link_get_name(), nm_platform_link_get_ifindex(), etc. are solely implemented based on looking at the returned NMPlatformLink object. No longer implement them as virtual functions but instead implement them in the base class (nm-platform.c). This removes code and eliminates the redundancy of the exposed NMPlatformLink instance and the nm_platform_link_get_*() accessors. Thereby also fix a bug in NMFakePlatform that tracked the link address in a separate "address" field, instead of using "link.addr". That was a case where the redundancy actually led to a bug in fake platform. Also remove some stub implementations in NMFakePlatform that just bail out. Instead allow for a missing virtual functions and perform the "default" action in the accessor. An example for that is nm_platform_link_get_permanent_address().
2015-06-20 12:05:01 +02:00
const NMPlatformLink *pllink;
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
int ifindex;
device: restore IP configuration when link comes up This is especially important, because changing MTU takes the link down for a moment. Taking a link down deletes IP routes and IPv6 addresses. Thus, when the link comes up again, we must restore them. Otherwise, we don't call merge_and_apply() until the next DHCP lease (or possibly never in case of static addressing). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-04-15 20:01:36 +02:00
gboolean was_up;
device: update unamanged by user-config when device gets renamed https://bugzilla.gnome.org/show_bug.cgi?id=766404
2016-05-16 17:36:56 +02:00
gboolean update_unmanaged_specs = FALSE;
device: re-read the current MAC address when the link changes The current MAC address is part of NMPlatformLink in the platform cache. When it changes, we must update the device's current value. Also, the MAC address of NMDeviceEthernet is exposed on D-Bus. That property should show the currently configured MAC address, not a state that was read some time in the past. Also, nm_device_hw_addr_set() compares the current MAC address before resetting it. If that field is out-of-date, nm_device_hw_addr_set() will behave wrongly. NMDeviceEthernet had some special handling in link_changed() that would re-read the MAC addresses and possibly bring up the interface. Move that code to the parent device.
2016-05-24 13:45:58 +02:00
gboolean got_hw_addr = FALSE, had_hw_addr;
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
priv->device_link_changed_id = 0;
ifindex = nm_device_get_ifindex (self);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
pllink = nm_platform_link_get (nm_device_get_platform (self), ifindex);
platform: refactor virtual methods for link objects in NMPlatform Change nm_platform_link_get() to return the cached NMPlatformLink instance. Now what all our implementations (fake and linux) have such a cache internal object, let's just expose it directly. Note that the lifetime of the exposed link object is possibly quite short. A caller must copy the returned value if he intends to preserve it for later. Also add nm_platform_link_get_by_ifname() and modify nm_platform_link_get_by_address() to return the instance. Certain functions, such as nm_platform_link_get_name(), nm_platform_link_get_ifindex(), etc. are solely implemented based on looking at the returned NMPlatformLink object. No longer implement them as virtual functions but instead implement them in the base class (nm-platform.c). This removes code and eliminates the redundancy of the exposed NMPlatformLink instance and the nm_platform_link_get_*() accessors. Thereby also fix a bug in NMFakePlatform that tracked the link address in a separate "address" field, instead of using "link.addr". That was a case where the redundancy actually led to a bug in fake platform. Also remove some stub implementations in NMFakePlatform that just bail out. Instead allow for a missing virtual functions and perform the "default" action in the accessor. An example for that is nm_platform_link_get_permanent_address().
2015-06-20 12:05:01 +02:00
if (!pllink)
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
return G_SOURCE_REMOVE;
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
pllink_keep_alive = nmp_object_ref (NMP_OBJECT_UP_CAST (pllink));
platform: don't wait for udev before announcing links
2015-04-13 16:29:37 -05:00
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
nm_device_update_from_platform_link (self, pllink);
device: always expose device statistics information Instead of updating the device-statistic counters only periodically as we refresh the link, update them on every link-changed event from platform. That means, also for devices that have RefreshRateMs at zero, the values will be updated at random times when the link information changes. The difference is, that previously the counters would be zero unless RefreshRateMs was set. Now, they have some (probably stale) values which however are not guaranteed to be kept up-to-date. Also, now we refresh more often then promised by RefreshRateMs. But the API technically doesn't specify that, so if we find there is a problem with this, we may revert it later.
2016-08-16 15:55:04 +02:00
device: re-read the current MAC address when the link changes The current MAC address is part of NMPlatformLink in the platform cache. When it changes, we must update the device's current value. Also, the MAC address of NMDeviceEthernet is exposed on D-Bus. That property should show the currently configured MAC address, not a state that was read some time in the past. Also, nm_device_hw_addr_set() compares the current MAC address before resetting it. If that field is out-of-date, nm_device_hw_addr_set() will behave wrongly. NMDeviceEthernet had some special handling in link_changed() that would re-read the MAC addresses and possibly bring up the interface. Move that code to the parent device.
2016-05-24 13:45:58 +02:00
had_hw_addr = (priv->hw_addr != NULL);
nm_device_update_hw_address (self);
got_hw_addr = (!had_hw_addr && priv->hw_addr);
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
nm_device_update_permanent_hw_address (self, FALSE);
device: re-read the current MAC address when the link changes The current MAC address is part of NMPlatformLink in the platform cache. When it changes, we must update the device's current value. Also, the MAC address of NMDeviceEthernet is exposed on D-Bus. That property should show the currently configured MAC address, not a state that was read some time in the past. Also, nm_device_hw_addr_set() compares the current MAC address before resetting it. If that field is out-of-date, nm_device_hw_addr_set() will behave wrongly. NMDeviceEthernet had some special handling in link_changed() that would re-read the MAC addresses and possibly bring up the interface. Move that code to the parent device.
2016-05-24 13:45:58 +02:00
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
if (pllink->name[0] && strcmp (priv->iface, pllink->name) != 0) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_DEVICE, "interface index %d renamed iface from '%s' to '%s'",
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
priv->ifindex, priv->iface, pllink->name);
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
g_free (priv->iface);
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
priv->iface = g_strdup (pllink->name);
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
/* If the device has no explicit ip_iface, then changing iface changes ip_iface too. */
ip_ifname_changed = !priv->ip_iface;
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
device: update unamanged by user-config when device gets renamed https://bugzilla.gnome.org/show_bug.cgi?id=766404
2016-05-16 17:36:56 +02:00
if (nm_device_get_unmanaged_flags (self, NM_UNMANAGED_PLATFORM_INIT))
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
nm_device_set_unmanaged_by_user_settings (self);
device: update unamanged by user-config when device gets renamed https://bugzilla.gnome.org/show_bug.cgi?id=766404
2016-05-16 17:36:56 +02:00
else
update_unmanaged_specs = TRUE;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IFACE);
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
if (ip_ifname_changed)
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IP_IFACE);
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
/* Re-match available connections against the new interface name */
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_recheck_available_connections (self);
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
/* Let any connections that use the new interface name have a chance
* to auto-activate on the device.
*/
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_emit_recheck_auto_activate (self);
device: add 'mtu' property
2013-12-16 15:16:43 +01:00
}
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
if (priv->ndisc && pllink->inet6_token.id) {
if (nm_ndisc_set_iid (priv->ndisc, pllink->inet6_token))
platform: remove nm_platform_link_get_ipv6_token() No need for the extra cache lookup.
2016-04-29 21:34:06 +02:00
_LOGD (LOGD_DEVICE, "IPv6 tokenized identifier present on device %s", priv->iface);
core: Use tokenized identifiers when constructing an address We trigger a new solicitation upon seeing the new token. Kernel triggers one too, but that one is of no use to us, since the advertisement might arrive sooner than we learn about the token change.
2014-09-27 09:04:46 +02:00
}
device: do nothing in NMDevice's link_changed() function All implementations of link_changed() chain up to NMDevice's base implementation. Thus, everybody wants to set the carrier. Refactor the code to set the carrier outside of link_changed().
2017-01-02 15:47:16 +01:00
/* Update carrier from link event if applicable. */
if ( nm_device_has_capability (self, NM_DEVICE_CAP_CARRIER_DETECT)
&& !nm_device_has_capability (self, NM_DEVICE_CAP_NONSTANDARD_CARRIER))
nm_device_set_carrier (self, pllink->connected);
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
klass->link_changed (self, pllink);
devices: fix link-changed refactoring Thomas points out that the previous refactoring moved the link_changed() virtual method invocation relative to update_for_ip_ifname_change(), which could have weird side effects given the things that can happen there. So move it back.
2014-05-19 09:56:29 -04:00
/* Update DHCP, etc, if needed */
if (ip_ifname_changed)
device: renew dhcp leases on awake for software devices This makes sure that devices like bond get their dhcp renewed [thaller@redhat.com: original patch modified to rename now-public function update_dynamic_ip_setup()] https://bugzilla.gnome.org/show_bug.cgi?id=764398
2016-03-26 01:26:36 -04:00
nm_device_update_dynamic_ip_setup (self);
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
device: restore IP configuration when link comes up This is especially important, because changing MTU takes the link down for a moment. Taking a link down deletes IP routes and IPv6 addresses. Thus, when the link comes up again, we must restore them. Otherwise, we don't call merge_and_apply() until the next DHCP lease (or possibly never in case of static addressing). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-04-15 20:01:36 +02:00
was_up = priv->up;
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
priv->up = NM_FLAGS_HAS (pllink->n_ifi_flags, IFF_UP);
device: fix race wrongly managing external-down device due to late udev signal Executing: # brctl addbr lbr0 # ip addr add 10.1.1.1/24 dev lbr0 # ip link set lbr0 up can result in a race so that NetworkManager would manage the device (and clear the IP addresses). It happens, when NetworkManager first receives platform signals that the device is already up: signal: link changed: 11: lbr0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 1500 arp 1 bridge* not-init addrgenmode eui64 addr D2:A1:B4:17:18:F2 driver bridge Note that the device is still unknown via udev (not-init). The unmanaged-state NM_UNMANAGED_EXTERNAL_DOWN gets cleared, but the device still stays unmanaged. Only afterwards the device is known in udev: signal: link changed: 11: lbr0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 1500 arp 1 bridge* init addrgenmode eui64 addr D2:A1:B4:17:18:F2 driver bridge At this point, we also clear NM_UNMANAGED_PLATFORM_INIT, making the device managed with reason NM_DEVICE_STATE_REASON_NOW_MANAGED. That results in managing the external device. Fix that by only clearing NM_UNMANAGED_EXTERNAL_DOWN after the device is no longer NM_UNMANAGED_PLATFORM_INIT. https://bugzilla.redhat.com/show_bug.cgi?id=1269199
2015-10-08 11:11:42 +02:00
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
if ( pllink->initialized
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
&& nm_device_get_unmanaged_flags (self, NM_UNMANAGED_PLATFORM_INIT)) {
device: don't allways set assumed reason when platform init is done When the device is transitioning from unmanaged to disconnected for "assumed" reason, bring_up is not called. This is not a good thing in numerous instances, e.g.: 1.) vlans that we've created need that to set IFF_UP and read carrier otherwise they won't be available for connections. 2.) veths that are being managed need to start the deferred carrier check so that the behavior matches real Ethernet. 3.) Hardware devices that were plugged in while NetworkManager is running that need the IFF_UP for a carrier check, possibly enqueueing a deferred one. Fixes: 5637d72af2d51b6f2b8dbe70553754f1828fdb66.
2016-02-18 16:13:23 +01:00
NMDeviceStateReason reason;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_by_user_udev (self);
device: add configuration option to mark devices as unmanaged We already have various ways to mark a device as unmanaged. 1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus at runtime. 2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and keyfile.unmanaged-devices in NetworkManager.conf. 3) at runtime, via D-Bus. This is persisted in the run state file and persists restarts (but not reboot). This adds another way via NetworkManager.conf file. Note that the existing keyfile.unmanaged-devices (above 2) is also a configuration optin in NetworkManager.conf. However it has various downsides: - it cannot be overwritten at runtime (see commit c210134bd58ea40ee3458aff27ab41958e1f48b4). - you can only explicitly mark a device as unmanaged. That means, you cannot use it to manage a device which is unmanaged due to a udev rule. - the name "keyfile.*" sounds like it's only relevant for the keyfile settings plugin. Nowadays the keyfile plugin is always loaded, so the option applies to NetworkManager in general. https://github.com/NetworkManager/NetworkManager/pull/29
2017-09-26 16:28:49 +02:00
nm_device_set_unmanaged_by_user_conf (self);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
device: let managed by user-udev overwrite external-down An externally configured software device is considered external-down until it is IF_UP and has IP configuration. When the user explicitly manages the device via UDEV rule, that decision should overrule external-down.
2016-04-08 11:36:13 +02:00
reason = NM_DEVICE_STATE_REASON_NOW_MANAGED;
device: refactor setting unmanaged flag EXTERNAL_DOWN This should not actually change how we handle EXTERNAL_DOWN unmanaged devices.
2016-03-21 14:56:15 +01:00
/* If the device is a external-down candidated but no longer has external
* down set, we must clear the platform-unmanaged flag with reason
* "assumed". */
if ( nm_device_get_unmanaged_mask (self, NM_UNMANAGED_EXTERNAL_DOWN)
&& !nm_device_get_unmanaged_flags (self, NM_UNMANAGED_EXTERNAL_DOWN)) {
device: let managed by user-udev overwrite external-down An externally configured software device is considered external-down until it is IF_UP and has IP configuration. When the user explicitly manages the device via UDEV rule, that decision should overrule external-down.
2016-04-08 11:36:13 +02:00
/* actually, user-udev overwrites external-down. So we only assume the device,
* when it is a external-down candidate, which is not managed via udev. */
if (!nm_device_get_unmanaged_mask (self, NM_UNMANAGED_USER_UDEV)) {
/* Ensure the assume check is queued before any queued state changes
* from the transition to UNAVAILABLE.
*/
nm_device_queue_recheck_assume (self);
reason = NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED;
}
}
device: don't allways set assumed reason when platform init is done When the device is transitioning from unmanaged to disconnected for "assumed" reason, bring_up is not called. This is not a good thing in numerous instances, e.g.: 1.) vlans that we've created need that to set IFF_UP and read carrier otherwise they won't be available for connections. 2.) veths that are being managed need to start the deferred carrier check so that the behavior matches real Ethernet. 3.) Hardware devices that were plugged in while NetworkManager is running that need the IFF_UP for a carrier check, possibly enqueueing a deferred one. Fixes: 5637d72af2d51b6f2b8dbe70553754f1828fdb66.
2016-02-18 16:13:23 +01:00
nm_device_set_unmanaged_by_flags (self, NM_UNMANAGED_PLATFORM_INIT, FALSE, reason);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
}
core: fix re-activation of connections on EXTERNAL_DOWN interfaces (bgo #741742) When userspace IPv6LL capability is compiled into NetworkManager, during deactivation NM will toggle userspace IPv6LL in some cases. This causes link change events in the platform, which show up in nm-device.c::device_link_changed(). When an EXTERNAL_DOWN interface was activated, the EXTERNAL_DOWN flag was never cleared even if the device was set IFF_UP or if a connection was activated via D-Bus (which explicitly sets the device up). Second, the device_link_changed() code changed device state whether or not IFF_UP had actually changed, it simply looked at the current value. Together, this caused the first activation of an EXTERNAL_DOWN device to succeed, but the EXTERNAL_DOWN flag was never cleared even though the activation set the device IFF_UP. When a second activation request came in, the device was moved to DISCONNECTED state and IPv6LL genmode was reset, causing device_link_changed() to run. Since the device had EXTERNAL_DOWN and IFF_UP were still set, nm_device_set_unmanaged_flag() code was triggered to clear EXTERNAL_DOWN, which resulted in a state transition to UNAVAILABLE with a reason of CONNECTION_ASSUMED. This caused the second activation request to fail because UNAVAILABLE devices cannot activate connections by definition. The fix has three parts: 1) Only change EXTERNAL_DOWN if IFF_UP actually changes, to prevent spurious changes when something other than IFF_UP changes 2) Only clear EXTERNAL_DOWN when IFF_UP changes while the device is UNMANAGED, since any state higher than UNMANAGED implies that either an activation request was received (and thus the device should be managed) or IFF_UP was set 3) Clear EXTERNAL_DOWN (without triggering state changes) when any state higher than UNAVAILABLE is entered, since this implies that a connection is activating or the device is no longer IFF_UP fixes:NetworkManager_Test108_testcase_303655 https://bugzilla.gnome.org/show_bug.cgi?id=741742
2014-12-18 23:38:37 -06:00
device: consider external devices as unmanaged until they have an IP address
2016-03-21 15:30:07 +01:00
set_unmanaged_external_down (self, FALSE);
platform: don't wait for udev before announcing links
2015-04-13 16:29:37 -05:00
device: keep platform link alive in device_link_changed() For a while now, all NMPObject instances are not modified after being cached. They are immutable, and can be passed around by keeping a reference to them. No longer copy the NMPlatformLink data to a @info variable. Instead, take a reference (which ensures that the instance stays alive). It won't change, as it's immutable. The advantage is, that whenever you see a NMPlatformLink pointer, for exmple in device_recheck_slave_status(), you can be sure that it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
2017-10-27 11:56:20 +02:00
device_recheck_slave_status (self, pllink);
device: restore IP configuration when link comes up This is especially important, because changing MTU takes the link down for a moment. Taking a link down deletes IP routes and IPv6 addresses. Thus, when the link comes up again, we must restore them. Otherwise, we don't call merge_and_apply() until the next DHCP lease (or possibly never in case of static addressing). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-04-15 20:01:36 +02:00
if (priv->up && !was_up) {
/* the link was down and just came up. That happens for example, while changing MTU.
* We must restore IP configuration. */
if (priv->ip4_state == IP_DONE) {
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
if (!ip4_config_merge_and_apply (self, TRUE))
device: restore IP configuration when link comes up This is especially important, because changing MTU takes the link down for a moment. Taking a link down deletes IP routes and IPv6 addresses. Thus, when the link comes up again, we must restore them. Otherwise, we don't call merge_and_apply() until the next DHCP lease (or possibly never in case of static addressing). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-04-15 20:01:36 +02:00
_LOGW (LOGD_IP4, "failed applying IP4 config after link comes up again");
}
if (priv->ip6_state == IP_DONE) {
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (!ip6_config_merge_and_apply (self, TRUE))
device: restore IP configuration when link comes up This is especially important, because changing MTU takes the link down for a moment. Taking a link down deletes IP routes and IPv6 addresses. Thus, when the link comes up again, we must restore them. Otherwise, we don't call merge_and_apply() until the next DHCP lease (or possibly never in case of static addressing). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-04-15 20:01:36 +02:00
_LOGW (LOGD_IP6, "failed applying IP6 config after link comes up again");
}
}
device: update unamanged by user-config when device gets renamed https://bugzilla.gnome.org/show_bug.cgi?id=766404
2016-05-16 17:36:56 +02:00
if (update_unmanaged_specs)
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
nm_device_set_unmanaged_by_user_settings (self);
device: update unamanged by user-config when device gets renamed https://bugzilla.gnome.org/show_bug.cgi?id=766404
2016-05-16 17:36:56 +02:00
device: re-read the current MAC address when the link changes The current MAC address is part of NMPlatformLink in the platform cache. When it changes, we must update the device's current value. Also, the MAC address of NMDeviceEthernet is exposed on D-Bus. That property should show the currently configured MAC address, not a state that was read some time in the past. Also, nm_device_hw_addr_set() compares the current MAC address before resetting it. If that field is out-of-date, nm_device_hw_addr_set() will behave wrongly. NMDeviceEthernet had some special handling in link_changed() that would re-read the MAC addresses and possibly bring up the interface. Move that code to the parent device.
2016-05-24 13:45:58 +02:00
if ( got_hw_addr
&& !priv->up
&& nm_device_get_state (self) == NM_DEVICE_STATE_UNAVAILABLE) {
/*
* If the device is UNAVAILABLE, any previous try to
* bring it up probably has failed because of the
* invalid hardware address; try again.
*/
nm_device_bring_up (self, TRUE, NULL);
nm_device_queue_recheck_available (self,
NM_DEVICE_STATE_REASON_NONE,
NM_DEVICE_STATE_REASON_NONE);
}
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
return G_SOURCE_REMOVE;
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
}
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
static gboolean
device_ip_link_changed (NMDevice *self)
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
platform: refactor virtual methods for link objects in NMPlatform Change nm_platform_link_get() to return the cached NMPlatformLink instance. Now what all our implementations (fake and linux) have such a cache internal object, let's just expose it directly. Note that the lifetime of the exposed link object is possibly quite short. A caller must copy the returned value if he intends to preserve it for later. Also add nm_platform_link_get_by_ifname() and modify nm_platform_link_get_by_address() to return the instance. Certain functions, such as nm_platform_link_get_name(), nm_platform_link_get_ifindex(), etc. are solely implemented based on looking at the returned NMPlatformLink object. No longer implement them as virtual functions but instead implement them in the base class (nm-platform.c). This removes code and eliminates the redundancy of the exposed NMPlatformLink instance and the nm_platform_link_get_*() accessors. Thereby also fix a bug in NMFakePlatform that tracked the link address in a separate "address" field, instead of using "link.addr". That was a case where the redundancy actually led to a bug in fake platform. Also remove some stub implementations in NMFakePlatform that just bail out. Instead allow for a missing virtual functions and perform the "default" action in the accessor. An example for that is nm_platform_link_get_permanent_address().
2015-06-20 12:05:01 +02:00
const NMPlatformLink *pllink;
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
priv->device_ip_link_changed_id = 0;
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
device: update @ip_iface only if IP interface exists If @ip_ifindex is zero, the IP interface has disappeared and there's no point in updating @ip_iface. Actually, unconditionally updating @ip_iface is dangerous because it breaks the assumption used by other functions (as nm_device_get_ip_ifindex()) that a non-NULL @ip_iface implies a valid @ip_ifindex. This was causing the scary failure: devices/nm-device.c:666:get_ip_iface_identifier: assertion failed: (ifindex) https://bugzilla.redhat.com/show_bug.cgi?id=1268617
2016-01-04 14:22:01 +01:00
if (!priv->ip_ifindex)
return G_SOURCE_REMOVE;
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
pllink = nm_platform_link_get (nm_device_get_platform (self), priv->ip_ifindex);
platform: refactor virtual methods for link objects in NMPlatform Change nm_platform_link_get() to return the cached NMPlatformLink instance. Now what all our implementations (fake and linux) have such a cache internal object, let's just expose it directly. Note that the lifetime of the exposed link object is possibly quite short. A caller must copy the returned value if he intends to preserve it for later. Also add nm_platform_link_get_by_ifname() and modify nm_platform_link_get_by_address() to return the instance. Certain functions, such as nm_platform_link_get_name(), nm_platform_link_get_ifindex(), etc. are solely implemented based on looking at the returned NMPlatformLink object. No longer implement them as virtual functions but instead implement them in the base class (nm-platform.c). This removes code and eliminates the redundancy of the exposed NMPlatformLink instance and the nm_platform_link_get_*() accessors. Thereby also fix a bug in NMFakePlatform that tracked the link address in a separate "address" field, instead of using "link.addr". That was a case where the redundancy actually led to a bug in fake platform. Also remove some stub implementations in NMFakePlatform that just bail out. Instead allow for a missing virtual functions and perform the "default" action in the accessor. An example for that is nm_platform_link_get_permanent_address().
2015-06-20 12:05:01 +02:00
if (!pllink)
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
return G_SOURCE_REMOVE;
device: always expose device statistics information Instead of updating the device-statistic counters only periodically as we refresh the link, update them on every link-changed event from platform. That means, also for devices that have RefreshRateMs at zero, the values will be updated at random times when the link information changes. The difference is, that previously the counters would be zero unless RefreshRateMs was set. Now, they have some (probably stale) values which however are not guaranteed to be kept up-to-date. Also, now we refresh more often then promised by RefreshRateMs. But the API technically doesn't specify that, so if we find there is a problem with this, we may revert it later.
2016-08-16 15:55:04 +02:00
_stats_update_counters_from_pllink (self, pllink);
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
if (_ip_iface_update (self, pllink->name))
device: renew dhcp leases on awake for software devices This makes sure that devices like bond get their dhcp renewed [thaller@redhat.com: original patch modified to rename now-public function update_dynamic_ip_setup()] https://bugzilla.gnome.org/show_bug.cgi?id=764398
2016-03-26 01:26:36 -04:00
nm_device_update_dynamic_ip_setup (self);
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
return G_SOURCE_REMOVE;
core: turn link_changed() into a proper virtual function
2013-07-27 10:41:44 +02:00
}
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
static void
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
link_changed_cb (NMPlatform *platform,
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
int obj_type_i,
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
int ifindex,
NMPlatformLink *info,
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
int change_type_i,
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
NMDevice *self)
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
{
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
const NMPlatformSignalChangeType change_type = change_type_i;
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
NMDevicePrivate *priv;
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
if (change_type != NM_PLATFORM_SIGNAL_CHANGED)
return;
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
if (ifindex == nm_device_get_ifindex (self)) {
if (!priv->device_link_changed_id) {
priv->device_link_changed_id = g_idle_add ((GSourceFunc) device_link_changed, self);
_LOGD (LOGD_DEVICE, "queued link change for ifindex %d", ifindex);
}
} else if (ifindex == nm_device_get_ip_ifindex (self)) {
if (!priv->device_ip_link_changed_id) {
priv->device_ip_link_changed_id = g_idle_add ((GSourceFunc) device_ip_link_changed, self);
_LOGD (LOGD_DEVICE, "queued link change for ip-ifindex %d", ifindex);
}
}
devices: refactor the link-changed code Separate out the "ifindex changed" and "ip_ifindex changed" cases.
2014-03-18 10:18:56 -04:00
}
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
/*****************************************************************************/
typedef struct {
in_addr_t network;
guint8 plen;
} IP4RPFilterData;
static guint
_v4_has_shadowed_routes_detect_hash (const IP4RPFilterData *d)
{
all: refactor hashing by introducing NMHashState The privious NM_HASH_* macros directly operated on a guint value and were thus close to the actual implementation. Replace them by adding a NMHashState struct and accessors to update the hash state. This hides the implementation better and would allow us to carry more state. For example, we could switch to siphash24() transparently. For now, we still do a form basically djb2 hashing, albeit with differing start seed. Also add nm_hash_str() and nm_str_hash(): - nm_hash_str() is our own string hashing implementation - nm_str_hash() is our own string implementation, but with a GHashFunc signature, suitable to pass it to g_hash_table_new(). Also, it has this name in order to remind you of g_str_hash(), which it is replacing.
2017-10-13 14:00:22 +02:00
NMHashState h;
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
all: refactor hashing by introducing NMHashState The privious NM_HASH_* macros directly operated on a guint value and were thus close to the actual implementation. Replace them by adding a NMHashState struct and accessors to update the hash state. This hides the implementation better and would allow us to carry more state. For example, we could switch to siphash24() transparently. For now, we still do a form basically djb2 hashing, albeit with differing start seed. Also add nm_hash_str() and nm_str_hash(): - nm_hash_str() is our own string hashing implementation - nm_str_hash() is our own string implementation, but with a GHashFunc signature, suitable to pass it to g_hash_table_new(). Also, it has this name in order to remind you of g_str_hash(), which it is replacing.
2017-10-13 14:00:22 +02:00
nm_hash_init (&h, 1105201169u);
core: refactor hashing to use reduce calls to siphash24_compress() This makes for example nm_platform_link_hash_update() by roughly 25% faster.
2017-10-17 13:28:25 +02:00
nm_hash_update_vals (&h,
d->network,
d->plen);
all: refactor hashing by introducing NMHashState The privious NM_HASH_* macros directly operated on a guint value and were thus close to the actual implementation. Replace them by adding a NMHashState struct and accessors to update the hash state. This hides the implementation better and would allow us to carry more state. For example, we could switch to siphash24() transparently. For now, we still do a form basically djb2 hashing, albeit with differing start seed. Also add nm_hash_str() and nm_str_hash(): - nm_hash_str() is our own string hashing implementation - nm_str_hash() is our own string implementation, but with a GHashFunc signature, suitable to pass it to g_hash_table_new(). Also, it has this name in order to remind you of g_str_hash(), which it is replacing.
2017-10-13 14:00:22 +02:00
return nm_hash_complete (&h);
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
}
static gboolean
_v4_has_shadowed_routes_detect_equal (const IP4RPFilterData *d1, const IP4RPFilterData *d2)
{
return d1->network == d2->network && d1->plen == d2->plen;
}
static gboolean
_v4_has_shadowed_routes_detect (NMDevice *self)
{
NMPlatform *platform;
int ifindex;
NMPLookup lookup;
const NMDedupMultiHeadEntry *head_entry;
NMDedupMultiIter iter;
const NMPObject *o;
guint data_len;
gs_unref_hashtable GHashTable *data_hash = NULL;
gs_free IP4RPFilterData *data_arr = NULL;
ifindex = nm_device_get_ip_ifindex (self);
if (ifindex <= 0)
return FALSE;
platform = nm_device_get_platform (self);
head_entry = nm_platform_lookup (platform,
nmp_lookup_init_addrroute (&lookup,
NMP_OBJECT_TYPE_IP4_ROUTE,
ifindex));
if (!head_entry)
return FALSE;
/* first, create a lookup index @data_hash for all network/plen pairs. */
data_len = 0;
data_arr = g_new (IP4RPFilterData, head_entry->len);
data_hash = g_hash_table_new ((GHashFunc) _v4_has_shadowed_routes_detect_hash,
(GEqualFunc) _v4_has_shadowed_routes_detect_equal);
nmp_cache_iter_for_each (&iter, head_entry, &o) {
const NMPlatformIP4Route *r = NMP_OBJECT_CAST_IP4_ROUTE (o);
IP4RPFilterData *d;
nm_assert (r->ifindex == ifindex);
platform: add support for routing tables to platform cache The upper layers still ignore all routes outside the main table. For now, just add support to NMPlatform.
2017-08-21 23:17:12 +02:00
if ( NM_PLATFORM_IP_ROUTE_IS_DEFAULT (r)
|| r->table_coerced)
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
continue;
d = &data_arr[data_len++];
d->network = nm_utils_ip4_address_clear_host_address (r->network, r->plen);
d->plen = r->plen;
g_hash_table_add (data_hash, d);
}
/* then, search if there is any route on another interface with the same
* network/plen destination. If yes, we consider this a multihoming
* setup. */
head_entry = nm_platform_lookup (platform,
nmp_lookup_init_obj_type (&lookup,
NMP_OBJECT_TYPE_IP4_ROUTE));
nmp_cache_iter_for_each (&iter, head_entry, &o) {
const NMPlatformIP4Route *r = NMP_OBJECT_CAST_IP4_ROUTE (o);
IP4RPFilterData d;
if ( r->ifindex == ifindex
platform: add support for routing tables to platform cache The upper layers still ignore all routes outside the main table. For now, just add support to NMPlatform.
2017-08-21 23:17:12 +02:00
|| NM_PLATFORM_IP_ROUTE_IS_DEFAULT (r)
|| r->table_coerced)
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
continue;
d.network = nm_utils_ip4_address_clear_host_address (r->network, r->plen);
d.plen = r->plen;
if (g_hash_table_contains (data_hash, &d))
return TRUE;
}
return FALSE;
}
device: apply a loose IPv4 rp_filter when it would interfere with multihoming The IPv4 Strict Reverse Path Forwarding filter (RFC 3704) drops legitimate traffic when the same route is present on multiple interfaces, which is a pretty common scenario for IPv4 hosts. In particular, if the traffic is routable via multiple interfaces it drops traffic incoming via the device that has lower metric on the route to the originating network. Among other things, this disrupts existing connection when the user connected to the Internet via Wi-Fi activates a Wired Ethernet connection that also has a default route. Also, the Strict filter (and Reverse Path filters in general) provide practically no value to hosts that have a default route. The solution this patch uses is to detect scenarios where Strict filter is known to interfere and switch to a saner RP filter on the affected links. Routes to the same network on multiple interfaces is a good indication the RP filter would drop the legitimate traffice from the link with a lower metric. This includes the default routes. In such cases, we switch to the Loose Reverse Path Forwarding. This addresses the problems the multihomed hosts face, at the cost of disabling filtering altogether when a default route is present. A Feasible Path Reverse Path Forwarding would address the main problems with the Strict filter, but it's not implemented by the Linux kernel.
2017-03-16 14:27:03 +00:00
static void
ip4_rp_filter_update (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
const char *ip4_rp_filter;
if ( priv->v4_has_shadowed_routes
core: rework handling of default-routes and drop NMDefaultRouteManager Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
2017-08-30 11:46:42 +02:00
|| nm_device_get_best_default_route (self, AF_INET)) {
device: apply a loose IPv4 rp_filter when it would interfere with multihoming The IPv4 Strict Reverse Path Forwarding filter (RFC 3704) drops legitimate traffic when the same route is present on multiple interfaces, which is a pretty common scenario for IPv4 hosts. In particular, if the traffic is routable via multiple interfaces it drops traffic incoming via the device that has lower metric on the route to the originating network. Among other things, this disrupts existing connection when the user connected to the Internet via Wi-Fi activates a Wired Ethernet connection that also has a default route. Also, the Strict filter (and Reverse Path filters in general) provide practically no value to hosts that have a default route. The solution this patch uses is to detect scenarios where Strict filter is known to interfere and switch to a saner RP filter on the affected links. Routes to the same network on multiple interfaces is a good indication the RP filter would drop the legitimate traffice from the link with a lower metric. This includes the default routes. In such cases, we switch to the Loose Reverse Path Forwarding. This addresses the problems the multihomed hosts face, at the cost of disabling filtering altogether when a default route is present. A Feasible Path Reverse Path Forwarding would address the main problems with the Strict filter, but it's not implemented by the Linux kernel.
2017-03-16 14:27:03 +00:00
if (nm_device_ipv4_sysctl_get_uint32 (self, "rp_filter", 0) != 1) {
/* Don't touch the rp_filter if it's not strict. */
return;
}
/* Loose rp_filter */
ip4_rp_filter = "2";
} else {
/* Default rp_filter */
ip4_rp_filter = NULL;
}
if (ip4_rp_filter != priv->ip4_rp_filter) {
nm_device_ipv4_sysctl_set (self, "rp_filter", ip4_rp_filter);
priv->ip4_rp_filter = ip4_rp_filter;
}
}
core: turn link_changed() into a proper virtual function
2013-07-27 10:41:44 +02:00
static void
device: make @pllink argument in link_changed() function const
2017-01-02 15:38:24 +01:00
link_changed (NMDevice *self, const NMPlatformLink *pllink)
core: turn link_changed() into a proper virtual function
2013-07-27 10:41:44 +02:00
{
device: do nothing in NMDevice's link_changed() function All implementations of link_changed() chain up to NMDevice's base implementation. Thus, everybody wants to set the carrier. Refactor the code to set the carrier outside of link_changed().
2017-01-02 15:47:16 +01:00
/* stub implementation of virtual function to allow subclasses to chain up. */
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
}
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
static gboolean
link_type_compatible (NMDevice *self,
NMLinkType link_type,
gboolean *out_compatible,
GError **error)
{
device: precisely match the link type to the platform device The unrealized device's factory could be using one particular link type, don't allow matching the device to a non-matching one.
2015-12-08 14:51:04 +01:00
NMDeviceClass *klass;
NMLinkType device_type;
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
guint i = 0;
device: precisely match the link type to the platform device The unrealized device's factory could be using one particular link type, don't allow matching the device to a non-matching one.
2015-12-08 14:51:04 +01:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
klass = NM_DEVICE_GET_CLASS (self);
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
if (!klass->link_types) {
NM_SET_OUT (out_compatible, FALSE);
g_set_error_literal (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"Device does not support platform links");
return FALSE;
}
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
device_type = self->_priv->link_type;
device: precisely match the link type to the platform device The unrealized device's factory could be using one particular link type, don't allow matching the device to a non-matching one.
2015-12-08 14:51:04 +01:00
if (device_type > NM_LINK_TYPE_UNKNOWN && device_type != link_type) {
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"Needed link type 0x%x does not match the platform link type 0x%X",
device_type, link_type);
return FALSE;
}
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
for (i = 0; klass->link_types[i] > NM_LINK_TYPE_UNKNOWN; i++) {
if (klass->link_types[i] == link_type)
return TRUE;
if (klass->link_types[i] == NM_LINK_TYPE_ANY)
return TRUE;
}
NM_SET_OUT (out_compatible, FALSE);
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"Device does not support platform link type 0x%X",
link_type);
return FALSE;
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
/**
device/trivial: rename realize/setup function in NMDevice
2016-01-10 14:56:05 +01:00
* nm_device_realize_start():
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
* @self: the #NMDevice
* @plink: an existing platform link or %NULL
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
* @assume_state_guess_assume: set the guess_assume state.
* @assume_state_connection_uuid: set the connection uuid to assume.
device: only set nm-owned from statefile during initial setup The state file should only be read initially when NM starts, that is: during NMManager's platform_query_devices(). At all later points, for example when a software device gets destroyed and re-realized, the state file is clearly no longer relevant. Hence, pass the set-nm-owned flag from NMManager to realize_start_setup(). This is very much the same as with the NM_UNMANAGED_FLAG_USER_EXPLICT flag, which we also read from the state-file.
2017-06-07 22:11:50 +02:00
* @set_nm_owned: for software device, if TRUE set nm-owned.
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
* @unmanaged_user_explicit: the user-explicit unmanaged flag to apply
* on the device initially.
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
* @out_compatible: %TRUE on return if @self is compatible with @plink
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
* @error: location to store error, or %NULL
*
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
* Initializes and sets up the device using existing backing resources. Before
device/trivial: rename realize/setup function in NMDevice
2016-01-10 14:56:05 +01:00
* the device is ready for use nm_device_realize_finish() must be called.
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
* @out_compatible will only be set if @plink is not %NULL, and
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
*
device: only set NMDevice as "real" at the end of nm_device_realize_finish() Only set the device as "real" at the end of nm_device_realize_finish(), not already during nm_device_realize_start()/realize_start_setup().
2016-01-12 10:38:16 +01:00
* Important: if nm_device_realize_start() returns %TRUE, the caller MUST
* also call nm_device_realize_finish() to balance g_object_freeze_notify().
*
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
* Returns: %TRUE on success, %FALSE on error
*/
gboolean
device/trivial: rename realize/setup function in NMDevice
2016-01-10 14:56:05 +01:00
nm_device_realize_start (NMDevice *self,
device: pass NMPlatformLink instance as const pointer
2016-01-10 15:13:20 +01:00
const NMPlatformLink *plink,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
gboolean assume_state_guess_assume,
const char *assume_state_connection_uuid,
device: only set nm-owned from statefile during initial setup The state file should only be read initially when NM starts, that is: during NMManager's platform_query_devices(). At all later points, for example when a software device gets destroyed and re-realized, the state file is clearly no longer relevant. Hence, pass the set-nm-owned flag from NMManager to realize_start_setup(). This is very much the same as with the NM_UNMANAGED_FLAG_USER_EXPLICT flag, which we also read from the state-file.
2017-06-07 22:11:50 +02:00
gboolean set_nm_owned,
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
NMUnmanFlagOp unmanaged_user_explicit,
device/trivial: rename realize/setup function in NMDevice
2016-01-10 14:56:05 +01:00
gboolean *out_compatible,
GError **error)
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
{
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
nm_auto_nmpobj const NMPObject *plink_keep_alive = NULL;
nm_assert (!plink || NMP_OBJECT_GET_TYPE (NMP_OBJECT_UP_CAST (plink)) == NMP_OBJECT_TYPE_LINK);
device: copy the plink instance before realize_start_setup() To make sure, we don't end up with a dangling pointer due to an intermediate platform access which may invalidate the pointer.
2016-08-16 15:40:08 +02:00
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
NM_SET_OUT (out_compatible, TRUE);
if (plink) {
if (g_strcmp0 (nm_device_get_iface (self), plink->name) != 0) {
NM_SET_OUT (out_compatible, FALSE);
g_set_error_literal (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"Device interface name does not match platform link");
return FALSE;
}
if (!link_type_compatible (self, plink->type, out_compatible, error))
return FALSE;
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
plink_keep_alive = nmp_object_ref (NMP_OBJECT_UP_CAST (plink));
device: copy the plink instance before realize_start_setup() To make sure, we don't end up with a dangling pointer due to an intermediate platform access which may invalidate the pointer.
2016-08-16 15:40:08 +02:00
}
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
realize_start_setup (self,
plink,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
assume_state_guess_assume,
assume_state_connection_uuid,
set_nm_owned,
unmanaged_user_explicit);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
return TRUE;
}
/**
* nm_device_create_and_realize():
* @self: the #NMDevice
* @connection: the #NMConnection being activated
* @parent: the parent #NMDevice if any
* @error: location to store error, or %NULL
*
* Creates any backing resources needed to realize the device to proceed
* with activating @connection.
*
* Returns: %TRUE on success, %FALSE on error
*/
gboolean
nm_device_create_and_realize (NMDevice *self,
NMConnection *connection,
NMDevice *parent,
GError **error)
{
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
nm_auto_nmpobj const NMPObject *plink_keep_alive = NULL;
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
platform: return pointer to NMPlatformLink object for add functions Let the link-add functions return the internal pointer to the platform link object. Similar to link-get, which doesn't copy the link either. Also adjust the sole users of the add-functions (create-and-realize) to take the pointer. Eventually we still copy the returned data, because accessing platform can invalidate the returned pointer. Thus we don't actually safe any copying by this (at least every use of the function currently leads to the data being copied). Still change it, because I think the API of NMPlatform should look like that.
2015-12-09 15:13:57 +01:00
const NMPlatformLink *plink = NULL;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
/* Must be set before device is realized */
device: rename priv->is_nm_owned to priv->nm_owned Only a matter of taste, but nm_device_get_is_nm_owned() sounds strange.
2017-05-31 16:42:05 +02:00
priv->nm_owned = !nm_platform_link_get_by_ifname (nm_device_get_platform (self), priv->iface);
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
device: rename priv->is_nm_owned to priv->nm_owned Only a matter of taste, but nm_device_get_is_nm_owned() sounds strange.
2017-05-31 16:42:05 +02:00
_LOGD (LOGD_DEVICE, "create (is %snm-owned)", priv->nm_owned ? "" : "not ");
device: minor logging changes to device creation
2016-01-12 17:07:04 +01:00
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
/* Create any resources the device needs */
if (NM_DEVICE_GET_CLASS (self)->create_and_realize) {
if (!NM_DEVICE_GET_CLASS (self)->create_and_realize (self, connection, parent, &plink, error))
return FALSE;
device: accept NULL plink For PPP devices we can't create a link in advance, as the link is created by pppd when the connection is established.
2017-06-30 17:49:44 +02:00
if (plink) {
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
nm_assert (NMP_OBJECT_GET_TYPE (NMP_OBJECT_UP_CAST (plink)) == NMP_OBJECT_TYPE_LINK);
plink_keep_alive = nmp_object_ref (NMP_OBJECT_UP_CAST (plink));
device: accept NULL plink For PPP devices we can't create a link in advance, as the link is created by pppd when the connection is established.
2017-06-30 17:49:44 +02:00
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
}
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
realize_start_setup (self,
plink,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
FALSE, /* assume_state_guess_assume */
NULL, /* assume_state_connection_uuid */
FALSE, NM_UNMAN_FLAG_OP_FORGET);
device/trivial: rename realize/setup function in NMDevice
2016-01-10 14:56:05 +01:00
nm_device_realize_finish (self, plink);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
if (nm_device_get_managed (self, FALSE)) {
nm_device_state_changed (self,
NM_DEVICE_STATE_UNAVAILABLE,
NM_DEVICE_STATE_REASON_NOW_MANAGED);
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
return TRUE;
}
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
void
nm_device_update_from_platform_link (NMDevice *self, const NMPlatformLink *plink)
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
const char *str;
int ifindex;
guint32 mtu;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
g_return_if_fail (plink == NULL || link_type_compatible (self, plink->type, NULL, NULL));
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
str = plink ? nm_platform_link_get_udi (nm_device_get_platform (self), plink->ifindex) : NULL;
if (g_strcmp0 (str, priv->udi)) {
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
g_free (priv->udi);
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
priv->udi = g_strdup (str);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_UDI);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
}
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
str = plink ? plink->name : NULL;
if (str && g_strcmp0 (str, priv->iface)) {
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
g_free (priv->iface);
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
priv->iface = g_strdup (str);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IFACE);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
}
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
str = plink ? plink->driver : NULL;
if (g_strcmp0 (str, priv->driver) != 0) {
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
g_free (priv->driver);
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
priv->driver = g_strdup (str);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_DRIVER);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
}
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
if (plink) {
priv->up = NM_FLAGS_HAS (plink->n_ifi_flags, IFF_UP);
if (plink->ifindex == nm_device_get_ip_ifindex (self))
_stats_update_counters_from_pllink (self, plink);
} else {
priv->up = FALSE;
}
mtu = plink ? plink->mtu : 0;
_set_mtu (self, mtu);
ifindex = plink ? plink->ifindex : 0;
if (priv->ifindex != ifindex) {
priv->ifindex = ifindex;
_notify (self, PROP_IFINDEX);
NM_DEVICE_GET_CLASS (self)->link_changed (self, plink);
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
}
core: allow setting SR-IOV num_vfs
2017-04-14 23:33:14 +02:00
static void
device_init_sriov_num_vfs (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
gs_free char *value = NULL;
int num_vfs;
if ( priv->ifindex > 0
&& nm_device_has_capability (self, NM_DEVICE_CAP_SRIOV)) {
value = nm_config_data_get_device_config (NM_CONFIG_GET_DATA,
device: use define for "sriov-num-vfs" config entry
2017-04-19 10:29:04 +02:00
NM_CONFIG_KEYFILE_KEY_DEVICE_SRIOV_NUM_VFS,
core: allow setting SR-IOV num_vfs
2017-04-14 23:33:14 +02:00
self,
NULL);
num_vfs = _nm_utils_ascii_str_to_int64 (value, 10, 0, G_MAXINT32, -1);
if (num_vfs >= 0) {
nm_platform_link_set_sriov_num_vfs (nm_device_get_platform (self),
priv->ifindex, num_vfs);
}
}
}
trivial: move some code around in nm-device.c
2015-05-26 14:06:35 -05:00
static void
device: re-apply sriov_numvfs after SIGHUP
2017-04-14 17:46:20 +02:00
config_changed (NMConfig *config,
NMConfigData *config_data,
NMConfigChangeFlags changes,
NMConfigData *old_data,
NMDevice *self)
trivial: move some code around in nm-device.c
2015-05-26 14:06:35 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if ( priv->state <= NM_DEVICE_STATE_DISCONNECTED
|| priv->state > NM_DEVICE_STATE_ACTIVATED)
priv->ignore_carrier = nm_config_data_get_ignore_carrier (config_data, self);
device: re-apply sriov_numvfs after SIGHUP
2017-04-14 17:46:20 +02:00
if (NM_FLAGS_HAS (changes, NM_CONFIG_CHANGE_VALUES))
device_init_sriov_num_vfs (self);
trivial: move some code around in nm-device.c
2015-05-26 14:06:35 -05:00
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
static void
device: have realize_start_notify() call link_changed() Most implementations of realize_start_notify() do the same for link_changed(). Let NMDevice's base implementation of realize_start_notify() call link_changed() -- which by default does notthing. This allows subclasses to only overwrite link_changed().
2017-01-02 15:53:18 +01:00
realize_start_notify (NMDevice *self,
const NMPlatformLink *pllink)
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
{
device: have realize_start_notify() call link_changed() Most implementations of realize_start_notify() do the same for link_changed(). Let NMDevice's base implementation of realize_start_notify() call link_changed() -- which by default does notthing. This allows subclasses to only overwrite link_changed().
2017-01-02 15:53:18 +01:00
/* the default implementation of realize_start_notify() just calls
* link_changed() -- which by default does nothing. */
NM_DEVICE_GET_CLASS (self)->link_changed (self, pllink);
device: move implementation of NMDevice:setup_start() to realize_start_setup() All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
2016-01-08 17:24:24 +01:00
}
/**
* realize_start_setup():
* @self: the #NMDevice
* @plink: the #NMPlatformLink if backed by a kernel netdevice
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
* @assume_state_guess_assume: set the guess_assume state.
* @assume_state_connection_uuid: set the connection uuid to assume.
device: only set nm-owned from statefile during initial setup The state file should only be read initially when NM starts, that is: during NMManager's platform_query_devices(). At all later points, for example when a software device gets destroyed and re-realized, the state file is clearly no longer relevant. Hence, pass the set-nm-owned flag from NMManager to realize_start_setup(). This is very much the same as with the NM_UNMANAGED_FLAG_USER_EXPLICT flag, which we also read from the state-file.
2017-06-07 22:11:50 +02:00
* @set_nm_owned: if TRUE and device is a software-device, set nm-owned.
* TRUE.
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
* @unmanaged_user_explicit: the user-explict unmanaged flag to set.
device: move implementation of NMDevice:setup_start() to realize_start_setup() All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
2016-01-08 17:24:24 +01:00
*
* Update the device from backing resource properties (like hardware
* addresses, carrier states, driver/firmware info, etc). This function
* should only change properties for this device, and should not perform
* any tasks that affect other interfaces (like master/slave or parent/child
* stuff).
*/
static void
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
realize_start_setup (NMDevice *self,
const NMPlatformLink *plink,
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
gboolean assume_state_guess_assume,
const char *assume_state_connection_uuid,
device: only set nm-owned from statefile during initial setup The state file should only be read initially when NM starts, that is: during NMManager's platform_query_devices(). At all later points, for example when a software device gets destroyed and re-realized, the state file is clearly no longer relevant. Hence, pass the set-nm-owned flag from NMManager to realize_start_setup(). This is very much the same as with the NM_UNMANAGED_FLAG_USER_EXPLICT flag, which we also read from the state-file.
2017-06-07 22:11:50 +02:00
gboolean set_nm_owned,
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
NMUnmanFlagOp unmanaged_user_explicit)
device: move implementation of NMDevice:setup_start() to realize_start_setup() All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
2016-01-08 17:24:24 +01:00
{
NMDevicePrivate *priv;
NMDeviceClass *klass;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
static guint32 id = 0;
device: add function to change device capabilites
2016-05-09 18:16:45 +02:00
NMDeviceCapabilities capabilities = 0;
device: fix multiple subscriptions to config-changed signal for ignore-carrier We would subscribe to config-changed signal during object-realize, however only unsubscribe during dispose(). Avoid multiple subscributions, and unsubscribe also when unrealizing the device. Also, always subscribe to the signal, even without capability NM_DEVICE_CAP_CARRIER_DETECT. In the next commit, we will re-read capabilities later on, so just always subscribe.
2016-05-11 16:53:16 +02:00
NMConfig *config;
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
guint real_rate;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
core: keep platform link object alive and don't copy it Sometimes, when we have a platform object, we need to keep it alive, because any subsequent platform operation might invalidate the object. Previously, we achieved that by copying the NMPlatformLink data. For a while now, all platform object are immuable and recounted. We should not copy the instance to a NMPlatformLink object, because then the instance is no longer a full NMPObject. Instead, just take an additional reference. Since the object must be immutable, that is just as safe. But now callees down the stack get a proper NMPObject instance, and might reference it too.
2017-09-29 16:58:24 +02:00
/* plink is a NMPlatformLink type, however, we require it to come from the platform
* cache (where else would it come from?). */
nm_assert (!plink || NMP_OBJECT_GET_TYPE (NMP_OBJECT_UP_CAST (plink)) == NMP_OBJECT_TYPE_LINK);
device: move implementation of NMDevice:setup_start() to realize_start_setup() All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
2016-01-08 17:24:24 +01:00
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
/* The device should not be realized */
device: only set NMDevice as "real" at the end of nm_device_realize_finish() Only set the device as "real" at the end of nm_device_realize_finish(), not already during nm_device_realize_start()/realize_start_setup().
2016-01-12 10:38:16 +01:00
g_return_if_fail (!priv->real);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
g_return_if_fail (nm_device_get_unmanaged_flags (self, NM_UNMANAGED_PLATFORM_INIT));
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
g_return_if_fail (priv->ip_ifindex <= 0);
g_return_if_fail (priv->ip_iface == NULL);
device: add assertions for queued_ip4_config_change() and queued_ip6_config_change()
2016-05-05 11:05:07 +02:00
g_return_if_fail (!priv->queued_ip4_config_id);
g_return_if_fail (!priv->queued_ip6_config_id);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device: minor logging changes to device creation
2016-01-12 17:07:04 +01:00
_LOGD (LOGD_DEVICE, "start setup of %s, kernel ifindex %d", G_OBJECT_TYPE_NAME (self), plink ? plink->ifindex : 0);
device: move implementation of NMDevice:setup_start() to realize_start_setup() All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
2016-01-08 17:24:24 +01:00
klass = NM_DEVICE_GET_CLASS (self);
device/trivial: rename realize/setup function in NMDevice
2016-01-10 14:56:05 +01:00
/* Balanced by a thaw in nm_device_realize_finish() */
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
g_object_freeze_notify (G_OBJECT (self));
device: set a per-device default MTU on activation In absence of an explicit MTU (either via user configuration, PPP or DHCP), set a default MTU on activation that depends on the device type. We only want to do that on the very first call to _commit_mtu(). Later calls (for example in response to new DHCP leases) skip over this step. This means, on activation the MTU will always be reset to a sensible value instead of preserving whatever was left from a previous configuration. This does not cover setting the MTU from the VPN plugin :(
2017-01-16 12:18:51 +01:00
priv->mtu_initialized = FALSE;
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
priv->mtu_initial = 0;
priv->ip6_mtu_initial = 0;
device: cleanup setting of mtu in NMDevice Mark priv->mtu/priv->ip_mtu/ priv->ip6_mtu as const to highlight the places that explicitly set their mutable aliases priv->mtu_/ priv->ip_mtu_/priv->ip6_mtu_. Also, NM_DEVICE_MTU property is read-only. It cannot be set via g_object_set(). Also, clear priv->mtu in nm_device_unrealize().
2017-01-13 15:55:48 +01:00
priv->ip6_mtu = 0;
device: set MTU property of device in new _set_mtu() function
2017-10-13 13:11:11 +02:00
_set_mtu (self, 0);
device: cleanup setting of mtu in NMDevice Mark priv->mtu/priv->ip_mtu/ priv->ip6_mtu as const to highlight the places that explicitly set their mutable aliases priv->mtu_/ priv->ip_mtu_/priv->ip6_mtu_. Also, NM_DEVICE_MTU property is read-only. It cannot be set via g_object_set(). Also, clear priv->mtu in nm_device_unrealize().
2017-01-13 15:55:48 +01:00
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
_assume_state_set (self, assume_state_guess_assume, assume_state_connection_uuid);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
nm_device_sys_iface_state_set (self, NM_DEVICE_SYS_IFACE_STATE_EXTERNAL);
manager: always update the device when the plink comes and goes For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
2017-08-16 15:44:24 +02:00
if (plink)
nm_device_update_from_platform_link (self, plink);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
if (priv->ifindex > 0) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
priv->physical_port_id = nm_platform_link_get_physical_port_id (nm_device_get_platform (self), priv->ifindex);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_PHYSICAL_PORT_ID);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
priv->dev_id = nm_platform_link_get_dev_id (nm_device_get_platform (self), priv->ifindex);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (nm_platform_link_is_software (nm_device_get_platform (self), priv->ifindex))
device: add function to change device capabilites
2016-05-09 18:16:45 +02:00
capabilities |= NM_DEVICE_CAP_IS_SOFTWARE;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device: set MTU property of device in new _set_mtu() function
2017-10-13 13:11:11 +02:00
_set_mtu (self,
nm_platform_link_get_mtu (nm_device_get_platform (self),
priv->ifindex));
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_get_driver_info (nm_device_get_platform (self),
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
priv->ifindex,
NULL,
&priv->driver_version,
&priv->firmware_version);
if (priv->driver_version)
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_DRIVER_VERSION);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
if (priv->firmware_version)
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_FIRMWARE_VERSION);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
platform: refactor detecting kernel support We are going to add another parameter to check. Instead of adding multiple virtual functions, add a NMPlatformKernelSupportFlags flags enum.
2017-10-10 18:20:05 +02:00
if (nm_platform_check_kernel_support (nm_device_get_platform (self),
NM_PLATFORM_KERNEL_SUPPORT_USER_IPV6LL))
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
priv->nm_ipv6ll = nm_platform_link_get_user_ipv6ll_enabled (nm_device_get_platform (self), priv->ifindex);
all: detect SR-IOV device support
2017-04-14 23:16:11 +02:00
if (nm_platform_link_supports_sriov (nm_device_get_platform (self), priv->ifindex))
capabilities |= NM_DEVICE_CAP_SRIOV;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
}
device: move implementation of NMDevice:setup_start() to realize_start_setup() All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
2016-01-08 17:24:24 +01:00
if (klass->get_generic_capabilities)
device: add function to change device capabilites
2016-05-09 18:16:45 +02:00
capabilities |= klass->get_generic_capabilities (self);
_add_capabilities (self, capabilities);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
manager: restore the previous persistent nm-owned state of devices After a daemon restart, any software device is considered !nm-owned, even if it was created by NM. Therefore, a device stays around even if the connection which created it gets deactivated or deleted. Fix this by remembering the previous nm-owned state in the device state file. https://bugzilla.redhat.com/show_bug.cgi?id=1376199
2017-05-31 16:58:21 +02:00
if ( !priv->nm_owned
device: only set nm-owned from statefile during initial setup The state file should only be read initially when NM starts, that is: during NMManager's platform_query_devices(). At all later points, for example when a software device gets destroyed and re-realized, the state file is clearly no longer relevant. Hence, pass the set-nm-owned flag from NMManager to realize_start_setup(). This is very much the same as with the NM_UNMANAGED_FLAG_USER_EXPLICT flag, which we also read from the state-file.
2017-06-07 22:11:50 +02:00
&& set_nm_owned
manager: restore the previous persistent nm-owned state of devices After a daemon restart, any software device is considered !nm-owned, even if it was created by NM. Therefore, a device stays around even if the connection which created it gets deactivated or deleted. Fix this by remembering the previous nm-owned state in the device state file. https://bugzilla.redhat.com/show_bug.cgi?id=1376199
2017-05-31 16:58:21 +02:00
&& nm_device_is_software (self)) {
device: only set nm-owned from statefile during initial setup The state file should only be read initially when NM starts, that is: during NMManager's platform_query_devices(). At all later points, for example when a software device gets destroyed and re-realized, the state file is clearly no longer relevant. Hence, pass the set-nm-owned flag from NMManager to realize_start_setup(). This is very much the same as with the NM_UNMANAGED_FLAG_USER_EXPLICT flag, which we also read from the state-file.
2017-06-07 22:11:50 +02:00
priv->nm_owned = TRUE;
_LOGD (LOGD_DEVICE, "set nm-owned from state file");
manager: restore the previous persistent nm-owned state of devices After a daemon restart, any software device is considered !nm-owned, even if it was created by NM. Therefore, a device stays around even if the connection which created it gets deactivated or deleted. Fix this by remembering the previous nm-owned state in the device state file. https://bugzilla.redhat.com/show_bug.cgi?id=1376199
2017-05-31 16:58:21 +02:00
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
if (!priv->udi) {
/* Use a placeholder UDI until we get a real one */
priv->udi = g_strdup_printf ("/virtual/device/placeholder/%d", id++);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_UDI);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
}
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
priv->queued_ip4_config_pending = TRUE;
priv->queued_ip6_config_pending = TRUE;
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
nm_device_update_hw_address (self);
device/trivial: split out nm_device_update_initial_hw_address()
2015-12-14 08:46:29 +01:00
nm_device_update_initial_hw_address (self);
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
nm_device_update_permanent_hw_address (self, FALSE);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
/* Note: initial hardware address must be read before calling get_ignore_carrier() */
device: fix multiple subscriptions to config-changed signal for ignore-carrier We would subscribe to config-changed signal during object-realize, however only unsubscribe during dispose(). Avoid multiple subscributions, and unsubscribe also when unrealizing the device. Also, always subscribe to the signal, even without capability NM_DEVICE_CAP_CARRIER_DETECT. In the next commit, we will re-read capabilities later on, so just always subscribe.
2016-05-11 16:53:16 +02:00
config = nm_config_get ();
priv->ignore_carrier = nm_config_data_get_ignore_carrier (nm_config_get_data (config), self);
device: re-apply sriov_numvfs after SIGHUP
2017-04-14 17:46:20 +02:00
if (!priv->config_changed_id) {
priv->config_changed_id = g_signal_connect (config,
device: fix multiple subscriptions to config-changed signal for ignore-carrier We would subscribe to config-changed signal during object-realize, however only unsubscribe during dispose(). Avoid multiple subscributions, and unsubscribe also when unrealizing the device. Also, always subscribe to the signal, even without capability NM_DEVICE_CAP_CARRIER_DETECT. In the next commit, we will re-read capabilities later on, so just always subscribe.
2016-05-11 16:53:16 +02:00
NM_CONFIG_SIGNAL_CONFIG_CHANGED,
device: re-apply sriov_numvfs after SIGHUP
2017-04-14 17:46:20 +02:00
G_CALLBACK (config_changed),
device: fix multiple subscriptions to config-changed signal for ignore-carrier We would subscribe to config-changed signal during object-realize, however only unsubscribe during dispose(). Avoid multiple subscributions, and unsubscribe also when unrealizing the device. Also, always subscribe to the signal, even without capability NM_DEVICE_CAP_CARRIER_DETECT. In the next commit, we will re-read capabilities later on, so just always subscribe.
2016-05-11 16:53:16 +02:00
self);
}
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
device: cleanup nm_device_set_carrier_from_platform() nm_device_set_carrier_from_platform() is only called from two places. - both check for NM_DEVICE_CAP_CARRIER_DETECT, so move that check inside the function. - drop the logging in realize_start_setup(). nm_device_set_carrier() already does logging. - always set the fake carrier in nm_device_set_carrier_from_platform(). For the fake carrer, we anyway expect it to be already TRUE in most case, so usually this should have no effect. Also emit a property changed signal. That is necessary to refresh the D-Bus property.
2017-05-15 11:35:41 +02:00
nm_device_set_carrier_from_platform (self);
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
core: allow setting SR-IOV num_vfs
2017-04-14 23:33:14 +02:00
device_init_sriov_num_vfs (self);
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
nm_assert (!priv->stats.timeout_id);
real_rate = _stats_refresh_rate_real (priv->stats.refresh_rate_ms);
device: always expose device statistics information Instead of updating the device-statistic counters only periodically as we refresh the link, update them on every link-changed event from platform. That means, also for devices that have RefreshRateMs at zero, the values will be updated at random times when the link information changes. The difference is, that previously the counters would be zero unless RefreshRateMs was set. Now, they have some (probably stale) values which however are not guaranteed to be kept up-to-date. Also, now we refresh more often then promised by RefreshRateMs. But the API technically doesn't specify that, so if we find there is a problem with this, we may revert it later.
2016-08-16 15:55:04 +02:00
if (real_rate)
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
priv->stats.timeout_id = g_timeout_add (real_rate, _stats_timeout_cb, self);
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
device: move implementation of NMDevice:setup_start() to realize_start_setup() All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
2016-01-08 17:24:24 +01:00
klass->realize_start_notify (self, plink);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
device: pass the user-explict flag to nm_device_realize_start() No change in behavior yet, because for unrealized devices the user-explict unmanaged flag is always cleared. The new option is still unused.
2016-09-26 14:45:35 +02:00
nm_assert (!nm_device_get_unmanaged_mask (self, NM_UNMANAGED_USER_EXPLICIT));
nm_device_set_unmanaged_flags (self,
NM_UNMANAGED_USER_EXPLICIT,
unmanaged_user_explicit);
device: refactor setting unmanaged flag EXTERNAL_DOWN This should not actually change how we handle EXTERNAL_DOWN unmanaged devices.
2016-03-21 14:56:15 +01:00
/* Do not manage externally created software devices until they are IFF_UP
* or have IP addressing */
nm_device_set_unmanaged_flags (self,
NM_UNMANAGED_EXTERNAL_DOWN,
is_unmanaged_external_down (self, TRUE));
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
/* Unmanaged the loopback device with an explicit NM_UNMANAGED_LOOPBACK flag.
* Later we might want to manage 'lo' too. Currently that doesn't work because
* NetworkManager might down the interface or remove the 127.0.0.1 address. */
nm_device_set_unmanaged_flags (self, NM_UNMANAGED_LOOPBACK, priv->ifindex == 1);
nm_device_set_unmanaged_by_user_udev (self);
device: add configuration option to mark devices as unmanaged We already have various ways to mark a device as unmanaged. 1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus at runtime. 2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and keyfile.unmanaged-devices in NetworkManager.conf. 3) at runtime, via D-Bus. This is persisted in the run state file and persists restarts (but not reboot). This adds another way via NetworkManager.conf file. Note that the existing keyfile.unmanaged-devices (above 2) is also a configuration optin in NetworkManager.conf. However it has various downsides: - it cannot be overwritten at runtime (see commit c210134bd58ea40ee3458aff27ab41958e1f48b4). - you can only explicitly mark a device as unmanaged. That means, you cannot use it to manage a device which is unmanaged due to a udev rule. - the name "keyfile.*" sounds like it's only relevant for the keyfile settings plugin. Nowadays the keyfile plugin is always loaded, so the option applies to NetworkManager in general. https://github.com/NetworkManager/NetworkManager/pull/29
2017-09-26 16:28:49 +02:00
nm_device_set_unmanaged_by_user_conf (self);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_flags (self, NM_UNMANAGED_PLATFORM_INIT,
plink && !plink->initialized);
device: add realize_start_setup() function Don't call the virtual function directly. Instead add a wrapper function.
2016-01-08 16:53:47 +01:00
}
device: remove unused virtual function NMDevice:setup_finish()
2016-01-08 17:08:54 +01:00
/**
device/trivial: rename realize/setup function in NMDevice
2016-01-10 14:56:05 +01:00
* nm_device_realize_finish():
device: remove unused virtual function NMDevice:setup_finish()
2016-01-08 17:08:54 +01:00
* @self: the #NMDevice
* @plink: the #NMPlatformLink if backed by a kernel netdevice
*
* Update the device's master/slave or parent/child relationships from
* backing resource properties. After this function finishes, the device
* is ready for network connectivity.
*/
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
void
device/trivial: rename realize/setup function in NMDevice
2016-01-10 14:56:05 +01:00
nm_device_realize_finish (NMDevice *self, const NMPlatformLink *plink)
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
{
device: only set NMDevice as "real" at the end of nm_device_realize_finish() Only set the device as "real" at the end of nm_device_realize_finish(), not already during nm_device_realize_start()/realize_start_setup().
2016-01-12 10:38:16 +01:00
NMDevicePrivate *priv;
g_return_if_fail (NM_IS_DEVICE (self));
core: ensure platform links are compatible with the NMDevice Ensure the platform link with the same interface name as the NMDevice is actually compatible with it before using the link for initialization of device properties. If not, remove the NMDevice and create a new one since there are kernel resources with a different type.
2014-10-09 12:42:29 -05:00
g_return_if_fail (!plink || link_type_compatible (self, plink->type, NULL, NULL));
device: only set NMDevice as "real" at the end of nm_device_realize_finish() Only set the device as "real" at the end of nm_device_realize_finish(), not already during nm_device_realize_start()/realize_start_setup().
2016-01-12 10:38:16 +01:00
priv = NM_DEVICE_GET_PRIVATE (self);
g_return_if_fail (!priv->real);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
if (plink)
device: remove unused virtual function NMDevice:setup_finish()
2016-01-08 17:08:54 +01:00
device_recheck_slave_status (self, plink);
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
device: only set NMDevice as "real" at the end of nm_device_realize_finish() Only set the device as "real" at the end of nm_device_realize_finish(), not already during nm_device_realize_start()/realize_start_setup().
2016-01-12 10:38:16 +01:00
priv->real = TRUE;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_REAL);
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
nm_device_recheck_available_connections (self);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
/* Balanced by a freeze in realize_start_setup(). */
core: split device creation and device setup (bgo #737458) Future patches will create devices long before they are backed by kernel resources, so we need to split NMDevice object creation from actual setup based on the backing resources. This patch combines the NMDeviceFactory's new_link() and create_virtual_device_for_connection() class methods into a single create_device() method that simply creates an unrealized NMDevice object; this method is not expected to fail unless the device is supposed to be ignored. This also means that the NMDevice 'platform-device' property is removed, because a platform link object may not be available at NMDevice object creation time. After the device is created, it is then "realized" at some later time from a platform link (for existing/hardware devices via the realize() method) or from an NMConnection (for newly created software devices via the create_and_realize() NMDeviceClass methods). https://bugzilla.gnome.org/show_bug.cgi?id=737458
2014-09-05 08:50:02 -05:00
g_object_thaw_notify (G_OBJECT (self));
}
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
static void
device: refactor virtual function NMDevice:unrealize_notify() to only clear properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
2016-01-10 15:19:58 +01:00
unrealize_notify (NMDevice *self)
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
{
device: refactor virtual function NMDevice:unrealize_notify() to only clear properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
2016-01-10 15:19:58 +01:00
/* Stub implementation for unrealize_notify(). It does nothing,
* but allows derived classes to uniformly invoke the parent
* implementation. */
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
device: remove unrealized device without connections on idle handler Emitting the NM_DEVICE_REMOVED signal can cause the destruction of the device, thus it should be emitted on an idle handler.
2016-01-19 11:33:33 +01:00
static gboolean
device/trivial: rename functions for available-connections
2016-01-20 18:02:34 +01:00
available_connections_check_delete_unrealized_on_idle (gpointer user_data)
device: remove unrealized device without connections on idle handler Emitting the NM_DEVICE_REMOVED signal can cause the destruction of the device, thus it should be emitted on an idle handler.
2016-01-19 11:33:33 +01:00
{
NMDevice *self = user_data;
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), G_SOURCE_REMOVE);
priv = NM_DEVICE_GET_PRIVATE (self);
priv->check_delete_unrealized_id = 0;
if ( g_hash_table_size (priv->available_connections) == 0
&& !nm_device_is_real (self))
g_signal_emit (self, signals[REMOVED], 0);
return G_SOURCE_REMOVE;
}
device: don't remove a devices on connection availability checks The availability checks are called from places that don't assume the device will be removed mid-air. Call the removal routine only when we're the very last thing that's being done.
2016-01-18 20:52:55 +01:00
static void
device/trivial: rename functions for available-connections
2016-01-20 18:02:34 +01:00
available_connections_check_delete_unrealized (NMDevice *self)
device: don't remove a devices on connection availability checks The availability checks are called from places that don't assume the device will be removed mid-air. Call the removal routine only when we're the very last thing that's being done.
2016-01-18 20:52:55 +01:00
{
device: remove unrealized device without connections on idle handler Emitting the NM_DEVICE_REMOVED signal can cause the destruction of the device, thus it should be emitted on an idle handler.
2016-01-19 11:33:33 +01:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
/* always rescheadule the remove signal. */
nm_clear_g_source (&priv->check_delete_unrealized_id);
device: don't remove a devices on connection availability checks The availability checks are called from places that don't assume the device will be removed mid-air. Call the removal routine only when we're the very last thing that's being done.
2016-01-18 20:52:55 +01:00
if ( g_hash_table_size (priv->available_connections) == 0
&& !nm_device_is_real (self))
device/trivial: rename functions for available-connections
2016-01-20 18:02:34 +01:00
priv->check_delete_unrealized_id = g_idle_add (available_connections_check_delete_unrealized_on_idle, self);
device: don't remove a devices on connection availability checks The availability checks are called from places that don't assume the device will be removed mid-air. Call the removal routine only when we're the very last thing that's being done.
2016-01-18 20:52:55 +01:00
}
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
/**
* nm_device_unrealize():
* @self: the #NMDevice
* @remove_resources: if %TRUE, remove backing resources
* @error: location to store error, or %NULL
*
* Clears any properties that depend on backing resources (kernel devices,
* etc) and removes those resources if @remove_resources is %TRUE.
*
* Returns: %TRUE on success, %FALSE on error
*/
gboolean
nm_device_unrealize (NMDevice *self, gboolean remove_resources, GError **error)
{
NMDevicePrivate *priv;
device: refactor virtual function NMDevice:unrealize_notify() to only clear properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
2016-01-10 15:19:58 +01:00
int ifindex;
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
if (!nm_device_is_software (self) || !nm_device_is_real (self)) {
g_set_error_literal (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_NOT_SOFTWARE,
"This device is not a software device or is not realized");
return FALSE;
}
priv = NM_DEVICE_GET_PRIVATE (self);
g_return_val_if_fail (priv->iface != NULL, FALSE);
device: only set NMDevice as "real" at the end of nm_device_realize_finish() Only set the device as "real" at the end of nm_device_realize_finish(), not already during nm_device_realize_start()/realize_start_setup().
2016-01-12 10:38:16 +01:00
g_return_val_if_fail (priv->real, FALSE);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
device: minor logging changes to device creation
2016-01-12 17:07:04 +01:00
ifindex = nm_device_get_ifindex (self);
_LOGD (LOGD_DEVICE, "unrealize (ifindex %d)", ifindex > 0 ? ifindex : 0);
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
nm_device_assume_state_reset (self);
device: refactor virtual function NMDevice:unrealize_notify() to only clear properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
2016-01-10 15:19:58 +01:00
if (remove_resources) {
infiniband: remove the partitions on unrealizing The infiniband drivers don't implement the rtnetlink link deletions. Therefore we unrealize the NMDevice instance but the backing resources stay around, preventing us from ever realizing the device again.
2016-04-20 09:16:41 +02:00
if (NM_DEVICE_GET_CLASS (self)->unrealize) {
if (!NM_DEVICE_GET_CLASS (self)->unrealize (self, error))
return FALSE;
} else if (ifindex > 0) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_delete (nm_device_get_platform (self), ifindex);
infiniband: remove the partitions on unrealizing The infiniband drivers don't implement the rtnetlink link deletions. Therefore we unrealize the NMDevice instance but the backing resources stay around, preventing us from ever realizing the device again.
2016-04-20 09:16:41 +02:00
}
device: refactor virtual function NMDevice:unrealize_notify() to only clear properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
2016-01-10 15:19:58 +01:00
}
device: fix frozen notify signals on unrealize error path If unrealize() failed we returned without thawing notify signals. Fix this by moving g_object_freeze_notify() after the unrealization/deletion but before the properties are reset in unrealize_notify(). Fixes: a93807c288743f499362f7edfe0674020762811c
2017-10-04 14:30:57 +02:00
g_object_freeze_notify (G_OBJECT (self));
device: refactor virtual function NMDevice:unrealize_notify() to only clear properties Change the meaning of unrealize_notify() similar to realize_start_notify(), which only resets device properites during unrealize.
2016-01-10 15:19:58 +01:00
NM_DEVICE_GET_CLASS (self)->unrealize_notify (self);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
_parent_set_ifindex (self, 0, FALSE);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
if (priv->ifindex > 0) {
priv->ifindex = 0;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IFINDEX);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
priv->ip_ifindex = 0;
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
if (nm_clear_g_free (&priv->ip_iface))
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IP_IFACE);
device: cleanup setting of ip-iface Move the updating/setting of the ip-ifindex/ip-iface to one place. Properties should be for the most part immutable/read-only, and only at particular places modified. That way, it's easier to track who changes a property. Also, add a logging line with "ip-ifname" prefix.
2016-12-26 18:11:03 +01:00
device: set MTU property of device in new _set_mtu() function
2017-10-13 13:11:11 +02:00
_set_mtu (self, 0);
device: cleanup setting of mtu in NMDevice Mark priv->mtu/priv->ip_mtu/ priv->ip6_mtu as const to highlight the places that explicitly set their mutable aliases priv->mtu_/ priv->ip_mtu_/priv->ip6_mtu_. Also, NM_DEVICE_MTU property is read-only. It cannot be set via g_object_set(). Also, clear priv->mtu in nm_device_unrealize().
2017-01-13 15:55:48 +01:00
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
if (priv->driver_version) {
g_clear_pointer (&priv->driver_version, g_free);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_DRIVER_VERSION);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
if (priv->firmware_version) {
g_clear_pointer (&priv->firmware_version, g_free);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_FIRMWARE_VERSION);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
if (priv->udi) {
g_clear_pointer (&priv->udi, g_free);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_UDI);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
if (priv->physical_port_id) {
g_clear_pointer (&priv->physical_port_id, g_free);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_PHYSICAL_PORT_ID);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
}
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
nm_clear_g_source (&priv->stats.timeout_id);
_stats_update_counters (self, 0, 0);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
priv->hw_addr_len_ = 0;
if (nm_clear_g_free (&priv->hw_addr))
_notify (self, PROP_HW_ADDRESS);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
priv->hw_addr_type = HW_ADDR_TYPE_UNSET;
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
if (nm_clear_g_free (&priv->hw_addr_perm))
_notify (self, PROP_PERM_HW_ADDRESS);
device/trivial: rename hw-addr related fields in NMDevicePrivate Next I will add two more fields. Being able to efficiently grep the code is important. I want to be able to grep for "->hw_addr" or "\<hw_addr" to find related stuff. Unfortunately, prefixes often result in backward English names, e.g. hw_addr_set/hw_addr_get. I still prefer that over get_hw_addr/set_hw_addr though.
2016-06-03 13:37:08 +02:00
g_clear_pointer (&priv->hw_addr_initial, g_free);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
priv->capabilities = NM_DEVICE_CAP_NM_SUPPORTED;
device: reset the capabilities to class defaults when reseting them Otherwise the lacking IS_SOFTWARE capability may cuase the connections not to be available on software devices and the devices would get garbage-collected at the end of unrealize().
2016-01-04 12:07:33 +01:00
if (NM_DEVICE_GET_CLASS (self)->get_generic_capabilities)
priv->capabilities |= NM_DEVICE_GET_CLASS (self)->get_generic_capabilities (self);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_CAPABILITIES);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
device: re-apply sriov_numvfs after SIGHUP
2017-04-14 17:46:20 +02:00
nm_clear_g_signal_handler (nm_config_get (), &priv->config_changed_id);
device: fix multiple subscriptions to config-changed signal for ignore-carrier We would subscribe to config-changed signal during object-realize, however only unsubscribe during dispose(). Avoid multiple subscributions, and unsubscribe also when unrealizing the device. Also, always subscribe to the signal, even without capability NM_DEVICE_CAP_CARRIER_DETECT. In the next commit, we will re-read capabilities later on, so just always subscribe.
2016-05-11 16:53:16 +02:00
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
priv->real = FALSE;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_REAL);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
g_object_thaw_notify (G_OBJECT (self));
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_flags (self,
NM_UNMANAGED_PLATFORM_INIT,
TRUE);
nm_device_set_unmanaged_flags (self,
NM_UNMANAGED_PARENT |
NM_UNMANAGED_LOOPBACK |
NM_UNMANAGED_USER_UDEV |
device: forget unmanaged-flag "user-explicit" for unrealized devices When a software device unrealizes, we want to forget about the "user-explict" unmanaged state. It means, that after a software device is deleted, the "user-explict" managed flag will be cleared for that device. It might be nice to preserve the managed-state after deletion of the device. However, the unrealized-device only exists as long as we have a connection for the device. That means, before this patch whether the unmanaged flag was forgotten depends on whether the user had some connections that keep the device alive as unrealized. That behavior was complicated, just don't do that.
2016-08-30 14:58:52 +02:00
NM_UNMANAGED_USER_EXPLICIT |
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
NM_UNMANAGED_EXTERNAL_DOWN |
NM_UNMANAGED_IS_SLAVE,
NM_UNMAN_FLAG_OP_FORGET);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
nm_device_state_changed (self,
NM_DEVICE_STATE_UNMANAGED,
remove_resources ?
NM_DEVICE_STATE_REASON_USER_REQUESTED : NM_DEVICE_STATE_REASON_NOW_UNMANAGED);
device: remove the unreferenced unreal devices When there's no connection that would use an unrealized device there's no more reason to keep the device in memory. It's in fact a resource leak.
2015-12-14 12:51:49 +01:00
/* Garbage-collect unneeded unrealized devices. */
nm_device_recheck_available_connections (self);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
return TRUE;
}
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
/**
* nm_device_notify_component_added():
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the #NMDevice
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
* @component: the component being added by a plugin
*
* Called by the manager to notify the device that a new component has
* been found. The device implementation should return %TRUE if it
* wishes to claim the component, or %FALSE if it cannot.
*
* Returns: %TRUE to claim the component, %FALSE if the component cannot be
* claimed.
*/
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_notify_component_added (NMDevice *self, GObject *component)
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
{
device: split new_device_added() out of component_added() Commit cd3df12c8f8ed6c868c12bc4e7fe6ba162dafc5b reused the virtual function component_added() to notify the vlan device about a possibly new parent. This reuse of the virtual function for another purpose is confusing. Clean that up by splitting the implementation and add a new virtual function nm_device_notify_new_device_added() which gets (only implemented by NMDeviceVlan).
2015-11-24 16:43:18 +01:00
NMDeviceClass *klass;
device: retry autoactivation upon a component addition It might have changed circumstances that were blocking the autoactivation.
2017-05-25 18:22:44 +02:00
NMDevicePrivate *priv;
device: split new_device_added() out of component_added() Commit cd3df12c8f8ed6c868c12bc4e7fe6ba162dafc5b reused the virtual function component_added() to notify the vlan device about a possibly new parent. This reuse of the virtual function for another purpose is confusing. Clean that up by splitting the implementation and add a new virtual function nm_device_notify_new_device_added() which gets (only implemented by NMDeviceVlan).
2015-11-24 16:43:18 +01:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
device: retry autoactivation upon a component addition It might have changed circumstances that were blocking the autoactivation.
2017-05-25 18:22:44 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
device: split new_device_added() out of component_added() Commit cd3df12c8f8ed6c868c12bc4e7fe6ba162dafc5b reused the virtual function component_added() to notify the vlan device about a possibly new parent. This reuse of the virtual function for another purpose is confusing. Clean that up by splitting the implementation and add a new virtual function nm_device_notify_new_device_added() which gets (only implemented by NMDeviceVlan).
2015-11-24 16:43:18 +01:00
klass = NM_DEVICE_GET_CLASS (self);
device: retry autoactivation upon a component addition It might have changed circumstances that were blocking the autoactivation.
2017-05-25 18:22:44 +02:00
if (priv->state == NM_DEVICE_STATE_DISCONNECTED) {
/* A device could have stayed disconnected because it would
* want to register with a network server that now become
* available. */
nm_device_recheck_available_connections (self);
if (g_hash_table_size (priv->available_connections) > 0)
nm_device_emit_recheck_auto_activate (self);
}
device: split new_device_added() out of component_added() Commit cd3df12c8f8ed6c868c12bc4e7fe6ba162dafc5b reused the virtual function component_added() to notify the vlan device about a possibly new parent. This reuse of the virtual function for another purpose is confusing. Clean that up by splitting the implementation and add a new virtual function nm_device_notify_new_device_added() which gets (only implemented by NMDeviceVlan).
2015-11-24 16:43:18 +01:00
if (klass->component_added)
return klass->component_added (self, component);
device: retry autoactivation upon a component addition It might have changed circumstances that were blocking the autoactivation.
2017-05-25 18:22:44 +02:00
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
return FALSE;
}
/**
* nm_device_owns_iface():
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the #NMDevice
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
* @iface: an interface name
*
* Called by the manager to ask if the device or any of its components owns
* @iface. For example, a WWAN implementation would return %TRUE for an
* ethernet interface name that was owned by the WWAN device's modem component,
* because that ethernet interface is controlled by the WWAN device and cannot
* be used independently of the WWAN device.
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* Returns: %TRUE if @self or it's components owns the interface name,
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
* %FALSE if not
*/
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_owns_iface (NMDevice *self, const char *iface)
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
if (NM_DEVICE_GET_CLASS (self)->owns_iface)
return NM_DEVICE_GET_CLASS (self)->owns_iface (self, iface);
devices: rework device plugin interface to be more flexible In preparation for making WWAN and Bluetooth plugins, rework the device plugin interface to meet those plugins' needs and port WiMAX over in the process.
2014-02-09 10:22:19 -06:00
return FALSE;
}
settings: create default wired connection from NMDeviceEthernet Instead of creating it in NMSettings, where we must use NM_IS_DEVICE_ETHERNET() (not NM_DEVICE_TYPE_ETHERNET because various generic devices masquerade as NM_DEVICE_TYPE_ETHERNET too), push knowledge of which device types create default wired connections into the device types themselves. This solves a problem with testcases where libNetworkManager.a (which testcases link to) requires the symbol nm_type_device_ethernet().
2014-09-08 16:11:51 -05:00
NMConnection *
nm_device_new_default_connection (NMDevice *self)
{
if (NM_DEVICE_GET_CLASS (self)->new_default_connection)
return NM_DEVICE_GET_CLASS (self)->new_default_connection (self);
return NULL;
}
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
static void
slave_state_changed (NMDevice *slave,
NMDeviceState slave_new_state,
NMDeviceState slave_old_state,
NMDeviceStateReason reason,
NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
gboolean release = FALSE;
device: don't release external slaves on state change If the slave is 'external' we should never touch it, in particular we should not release the link from its master; we only have to remove it from master's list. https://bugzilla.redhat.com/show_bug.cgi?id=1442361
2017-08-31 18:29:42 +02:00
gboolean configure;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "slave %s state change %d (%s) -> %d (%s)",
nm_device_get_iface (slave),
slave_old_state,
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (slave_old_state),
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
slave_new_state,
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (slave_new_state));
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
/* Don't try to enslave slaves until the master is ready */
if (priv->state < NM_DEVICE_STATE_CONFIG)
return;
if (slave_new_state == NM_DEVICE_STATE_IP_CONFIG)
device/trivial: rename master related function of nm-device We have the master/slave related functions - for master device: - nm_device_master_add_slave() - nm_device_master_release_slaves() - nm_device_release_one_slave() - nm_device_enslave_slave() - for slave device: - nm_device_slave_notify_enslave() - nm_device_slave_notify_release() Rename the two that didn't match the pattern to - nm_device_master_release_one_slave() - nm_device_master_enslave_slave()
2015-08-06 14:37:12 +02:00
nm_device_master_enslave_slave (self, slave, nm_device_get_applied_connection (slave));
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
else if (slave_new_state > NM_DEVICE_STATE_ACTIVATED)
release = TRUE;
else if ( slave_new_state <= NM_DEVICE_STATE_DISCONNECTED
&& slave_old_state > NM_DEVICE_STATE_DISCONNECTED) {
/* Catch failures due to unavailable or unmanaged */
release = TRUE;
}
if (release) {
device: don't release external slaves on state change If the slave is 'external' we should never touch it, in particular we should not release the link from its master; we only have to remove it from master's list. https://bugzilla.redhat.com/show_bug.cgi?id=1442361
2017-08-31 18:29:42 +02:00
configure = priv->sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_MANAGED
&& nm_device_sys_iface_state_get (slave) != NM_DEVICE_SYS_IFACE_STATE_EXTERNAL;
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
nm_device_master_release_one_slave (self, slave,
device: don't release external slaves on state change If the slave is 'external' we should never touch it, in particular we should not release the link from its master; we only have to remove it from master's list. https://bugzilla.redhat.com/show_bug.cgi?id=1442361
2017-08-31 18:29:42 +02:00
configure,
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
reason);
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
/* Bridge/bond/team interfaces are left up until manually deactivated */
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
if ( c_list_is_empty (&priv->slaves)
&& priv->state == NM_DEVICE_STATE_ACTIVATED)
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "last slave removed; remaining activated");
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
}
}
/**
* nm_device_master_add_slave:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the master device
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
* @slave: the slave device to enslave
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
* @configure: pass %TRUE if the slave should be configured by the master, or
* %FALSE if it is already configured outside NetworkManager
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* If @self is capable of enslaving other devices (ie it's a bridge, bond, team,
core: add support for team device Signed-off-by: Jiri Pirko <jiri@resnulli.us>
2013-07-25 15:36:45 +02:00
* etc) then this function adds @slave to the slave list for later enslavement.
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
*
* Returns: %TRUE if the slave was enslaved. %FALSE means, the slave was already
* enslaved and nothing was done.
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
*/
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
static gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_master_add_slave (NMDevice *self, NMDevice *slave, gboolean configure)
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
{
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
NMDevicePrivate *priv;
NMDevicePrivate *slave_priv;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
SlaveInfo *info;
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
gboolean changed = FALSE;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
g_return_val_if_fail (NM_IS_DEVICE (slave), FALSE);
g_return_val_if_fail (NM_DEVICE_GET_CLASS (self)->enslave_slave != NULL, FALSE);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
priv = NM_DEVICE_GET_PRIVATE (self);
slave_priv = NM_DEVICE_GET_PRIVATE (slave);
info = find_slave_info (self, slave);
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
_LOGT (LOGD_CORE, "master: add one slave %p/%s%s", slave, nm_device_get_iface (slave),
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
info ? " (already registered)" : "");
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
if (configure)
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
g_return_val_if_fail (nm_device_get_state (slave) >= NM_DEVICE_STATE_DISCONNECTED, FALSE);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
if (!info) {
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
g_return_val_if_fail (!slave_priv->master, FALSE);
g_return_val_if_fail (!slave_priv->is_enslaved, FALSE);
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
info = g_slice_new0 (SlaveInfo);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
info->slave = g_object_ref (slave);
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
info->configure = configure;
core: use define for NMDevice's "state-changed" signal name
2015-12-07 19:42:59 +01:00
info->watch_id = g_signal_connect (slave,
NM_DEVICE_STATE_CHANGED,
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
G_CALLBACK (slave_state_changed), self);
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
c_list_link_tail (&priv->slaves, &info->lst_slave);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
slave_priv->master = g_object_ref (self);
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
core: add NMActivationStateFlags "master-has-slaves"
2017-09-27 10:16:15 +02:00
_active_connection_set_state_flags (self,
NM_ACTIVATION_STATE_FLAG_MASTER_HAS_SLAVES);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
/* no need to emit
*
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
* _notify (slave, PROP_MASTER);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
*
* because slave_priv->is_enslaved is not true, thus the value
* didn't change yet. */
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
g_warn_if_fail (!NM_FLAGS_HAS (slave_priv->unmanaged_mask, NM_UNMANAGED_IS_SLAVE));
nm_device_set_unmanaged_by_flags (slave, NM_UNMANAGED_IS_SLAVE, FALSE, NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
changed = TRUE;
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
} else
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
g_return_val_if_fail (slave_priv->master == self, FALSE);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
nm_device_queue_recheck_assume (self);
device: connect slave assumption recheck on external enslavement The nm_device_master_add_slave() also modifies slave's master property which impacts the ability to enslave. When called in reaction to external master property change we now no longer call enslave_slave which used to queue the recheck previously: # nmcli c add type bridge ifname br0 # ip link add dummy0 type dummy # ip link set dummy0 up # ip link set dummy0 master br0 # We should recheck for assumed connection # here, since dummy0 can now be assumed.
2015-12-17 15:31:02 +01:00
nm_device_queue_recheck_assume (slave);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
device: return nm_device_master_add_slave() whether a slave was added This is currently not yet used. It will be later.
2017-03-01 17:28:46 +01:00
return changed;
}
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
/**
* nm_device_master_check_slave_physical_port:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the master device
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
* @slave: a slave device
* @log_domain: domain to log a warning in
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* Checks if @self already has a slave with the same #NMDevice:physical-port-id
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
* as @slave, and logs a warning if so.
*/
void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_master_check_slave_physical_port (NMDevice *self, NMDevice *slave,
core: use explict NMLogDomain enum instead of int A while ago (f4f3f4d69b6ff89b5ec7cb9b2ca3758c149f15f5) we added an enum to represent the logging domain. Use it.
2015-05-12 16:44:24 +02:00
NMLogDomain log_domain)
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
const char *slave_physical_port_id, *existing_physical_port_id;
SlaveInfo *info;
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
CList *iter;
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
slave_physical_port_id = nm_device_get_physical_port_id (slave);
if (!slave_physical_port_id)
return;
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
c_list_for_each (iter, &priv->slaves) {
info = c_list_entry (iter, SlaveInfo, lst_slave);
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
if (info->slave == slave)
continue;
existing_physical_port_id = nm_device_get_physical_port_id (info->slave);
if (!g_strcmp0 (slave_physical_port_id, existing_physical_port_id)) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (log_domain, "slave %s shares a physical port with existing slave %s",
nm_device_get_ip_iface (slave),
nm_device_get_ip_iface (info->slave));
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
/* Since this function will get called for every slave, we only have
* to warn about the first match we find; if there are other matches
* later in the list, we will have already warned about them matching
* @existing earlier.
*/
return;
}
}
}
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
/* release all slaves */
static void
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
nm_device_master_release_slaves (NMDevice *self)
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: fix warning releasing of slave when slave device gets removed When the slave device gets removed, the master is not in a state-change when calling nm_device_release_one_slave(). This triggers a warning [1]. [1] backtrace: #0 0x0000003370c504e9 in g_logv (log_domain=0x4c144c "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fff8b1d35b0) at gmessages.c:989 #1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x3370cc1fdc "%s") at gmessages.c:1025 #2 0x0000003370c50956 in g_warn_message (domain=domain@entry=0x4c144c "NetworkManager", file=file@entry=0x4b14d5 "devices/nm-device.c", line=line@entry=841, func=func@entry=0x4b48f0 <__FUNCTION__.35456> "nm_device_release_one_slave", warnexpr=warnexpr@entry=0x0) at gmessages.c:1058 #3 0x0000000000436c30 in nm_device_release_one_slave (dev=dev@entry=0xd92540, slave=slave@entry=0xdb0e50, configure=configure@entry=1) at devices/nm-device.c:841 #4 0x000000000043a779 in slave_state_changed (slave=0xdb0e50, slave_new_state=NM_DEVICE_STATE_UNMANAGED, slave_old_state=NM_DEVICE_STATE_ACTIVATED, reason=<optimized out>, self=0xd92540) at devices/nm-device.c:1214 #5 0x0000003371805d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76 #6 0x00000033718056bc in ffi_call (cif=cif@entry=0x7fff8b1d3a00, fn=0x43a677 <slave_state_changed>, rvalue=0x7fff8b1d3970, avalue=avalue@entry=0x7fff8b1d38f0) at ../src/x86/ffi64.c:522 #7 0x0000003371c10ad8 in g_cclosure_marshal_generic (closure=0xd76120, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454 #8 0x0000003371c10298 in g_closure_invoke (closure=0xd76120, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fff8b1d3c00, invocation_hint=invocation_hint@entry=0x7fff8b1d3ba0) at gclosure.c:777 #9 0x0000003371c2235d in signal_emit_unlocked_R (node=node@entry=0xd9d850, detail=detail@entry=0, instance=instance@entry=0xdb0e50, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff8b1d3c00) at gsignal.c:3586 #10 0x0000003371c2a0f2 in g_signal_emit_valist (instance=instance@entry=0xdb0e50, signal_id=signal_id@entry=68, detail=detail@entry=0, var_args=var_args@entry=0x7fff8b1d3e38) at gsignal.c:3330 #11 0x0000003371c2a8f8 in g_signal_emit_by_name (instance=instance@entry=0xdb0e50, detailed_signal=detailed_signal@entry=0x4c3ce2 "state-changed") at gsignal.c:3426 #12 0x000000000043754f in _set_state_full (device=device@entry=0xdb0e50, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6689 #13 0x000000000043797c in nm_device_state_changed (device=device@entry=0xdb0e50, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823 #14 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0xdb0e50, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983 #15 0x00000000004799c2 in remove_device (manager=manager@entry=0xd86150, device=0xdb0e50, quitting=quitting@entry=0) at nm-manager.c:769 #16 0x000000000047e3bf in platform_link_cb (platform=<optimized out>, ifindex=35, plink=<optimized out>, change_type=<optimized out>, reason=<optimized out>, user_data=<optimized out>) at nm-manager.c:2123 #17 0x0000003371805d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76 #18 0x00000033718056bc in ffi_call (cif=cif@entry=0x7fff8b1d4320, fn=0x47e34b <platform_link_cb>, rvalue=0x7fff8b1d4290, avalue=avalue@entry=0x7fff8b1d4210) at ../src/x86/ffi64.c:522 #19 0x0000003371c10ad8 in g_cclosure_marshal_generic (closure=0xd32e40, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454 #20 0x0000003371c10298 in g_closure_invoke (closure=0xd32e40, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff8b1d4520, invocation_hint=invocation_hint@entry=0x7fff8b1d44c0) at gclosure.c:777 #21 0x0000003371c2235d in signal_emit_unlocked_R (node=node@entry=0xcf5780, detail=detail@entry=0, instance=instance@entry=0xcf78a0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff8b1d4520) at gsignal.c:3586 #22 0x0000003371c2a0f2 in g_signal_emit_valist (instance=instance@entry=0xcf78a0, signal_id=signal_id@entry=2, detail=detail@entry=0, var_args=var_args@entry=0x7fff8b1d4778) at gsignal.c:3330 #23 0x0000003371c2a8f8 in g_signal_emit_by_name (instance=instance@entry=0xcf78a0, detailed_signal=detailed_signal@entry=0x4b183d "link-changed") at gsignal.c:3426 #24 0x000000000044c6f3 in announce_object (platform=platform@entry=0xcf78a0, object=0xde1720, change_type=change_type@entry=NM_PLATFORM_SIGNAL_REMOVED, reason=reason@entry=NM_PLATFORM_REASON_EXTERNAL) at platform/nm-linux-platform.c:1572 #25 0x000000000044ec07 in event_notification (msg=<optimized out>, user_data=<optimized out>) at platform/nm-linux-platform.c:1886 #26 0x0000003844c1117f in nl_cb_call (msg=<optimized out>, type=<optimized out>, cb=<optimized out>) at ../include/netlink-private/netlink.h:141 #27 recvmsgs (cb=0xcf7240, sk=0xcf7330) at nl.c:952 #28 nl_recvmsgs_report (sk=0xcf7330, cb=0xcf7240) at nl.c:1003 #29 0x0000003844c11549 in nl_recvmsgs (sk=<optimized out>, cb=<optimized out>) at nl.c:1027 #30 0x0000003844c11569 in nl_recvmsgs_default (sk=<optimized out>) at nl.c:1041 #31 0x000000000044e955 in event_handler (channel=<optimized out>, io_condition=<optimized out>, user_data=0xcf78a0) at platform/nm-linux-platform.c:3804 #32 0x0000003370c492a6 in g_main_dispatch (context=0xcf5190) at gmain.c:3066 #33 g_main_context_dispatch (context=context@entry=0xcf5190) at gmain.c:3642 #34 0x0000003370c49628 in g_main_context_iterate (context=0xcf5190, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #35 0x0000003370c49a3a in g_main_loop_run (loop=0xcf4e30) at gmain.c:3907 #36 0x0000000000429f15 in main (argc=1, argv=0x7fff8b1d4f38) at main.c:678 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-23 11:18:45 +02:00
NMDeviceStateReason reason;
device: don't tell the device to unconfigure if it's gone already After the device is unrealized a lot of its properites are reset. Notably, it doesn't have an ifindex anymore so there's nothing to unconfigure really. This makes at least NMDeviceBond unhappy: (bond device with a slave is removed externally) NetworkManager[21022]: <info> (bond0): device state change: activated -> unmanaged (reason 'unmanaged') [100 10 3] NetworkManager[21022]: nm_platform_link_release: assertion 'master > 0' failed Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555557592b1 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd370) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff4ec88c3 in g_logv (log_domain=0x5555557592b1 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd370) at gmessages.c:1046 #1 0x00007ffff4ec8a3f in g_log (log_domain=log_domain@entry=0x5555557592b1 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff4f3673d "%s: assertion '%s' failed") at gmessages.c:1079 #2 0x00007ffff4ec8a79 in g_return_if_fail_warning (log_domain=log_domain@entry=0x5555557592b1 "NetworkManager", pretty_function=pretty_function@entry=0x55555575ea50 <__FUNCTION__.33801> "nm_platform_link_relea8 #3 0x000055555560559a in nm_platform_link_release (self=0x555555a27bb0 [NMLinuxPlatform], master=master@entry=0, slave=slave@entry=3) at platform/nm-platform.c:1326 #4 0x00005555555b506e in release_slave (device=<optimized out>, slave=0x555555b6d770 [NMDeviceEthernet], configure=<optimized out>) at devices/nm-device-bond.c:423 #5 0x00005555555dab7b in nm_device_master_release_one_slave (self=self@entry=0x555555bf0cc0 [NMDeviceBond], slave=0x555555b6d770 [NMDeviceEthernet], configure=configure@entry=1, reason=reason@entry= NM_DEVICE_STATE_REASON_NOW_UNMANAGED) at devices/nm-device.c:1137 #6 0x00005555555dadb6 in nm_device_master_release_slaves (self=self@entry=0x555555bf0cc0 [NMDeviceBond]) at devices/nm-device.c:2344 #7 0x00005555555dd12f in nm_device_cleanup (self=self@entry=0x555555bf0cc0 [NMDeviceBond], reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_UNMANAGED, cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE) at devices/nm-device.c:9133 #8 0x00005555555de3ea in _set_state_full (self=self@entry=0x555555bf0cc0 [NMDeviceBond], state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry= NM_DEVICE_STATE_REASON_NOW_UNMANAGED, quitting=quitting@entry=0) at devices/nm-device.c:9510 #9 0x00005555555dedb7 in nm_device_state_changed (self=self@entry=0x555555bf0cc0 [NMDeviceBond], state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_UNMANAGED) at devices/nm-device.c:9769 #10 0x00005555555e11b4 in nm_device_unrealize (self=self@entry=0x555555bf0cc0 [NMDeviceBond], remove_resources=remove_resources@entry=0, error=error@entry=0x7fffffffd788) at devices/nm-device.c:2062 #11 0x000055555565c9c5 in _platform_link_cb_idle (data=0x555555c6e2b0) at nm-manager.c:2055 #12 0x00007ffff4ec179a in g_main_context_dispatch (context=0x555555a226c0) at gmain.c:3109 #13 0x00007ffff4ec179a in g_main_context_dispatch (context=context@entry=0x555555a226c0) at gmain.c:3708 #14 0x00007ffff4ec1ae8 in g_main_context_iterate (context=0x555555a226c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3779 #15 0x00007ffff4ec1dba in g_main_loop_run (loop=0x555555a22780) at gmain.c:3973 #16 0x00005555555b3e5f in main (argc=1, argv=0x7fffffffdb18) at main.c:488
2015-12-11 17:23:51 +01:00
gboolean configure = TRUE;
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
CList *iter, *safe;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
/* Don't release the slaves if this connection doesn't belong to NM. */
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (nm_device_sys_iface_state_is_external (self))
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
return;
device: fix warning releasing of slave when slave device gets removed When the slave device gets removed, the master is not in a state-change when calling nm_device_release_one_slave(). This triggers a warning [1]. [1] backtrace: #0 0x0000003370c504e9 in g_logv (log_domain=0x4c144c "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fff8b1d35b0) at gmessages.c:989 #1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x3370cc1fdc "%s") at gmessages.c:1025 #2 0x0000003370c50956 in g_warn_message (domain=domain@entry=0x4c144c "NetworkManager", file=file@entry=0x4b14d5 "devices/nm-device.c", line=line@entry=841, func=func@entry=0x4b48f0 <__FUNCTION__.35456> "nm_device_release_one_slave", warnexpr=warnexpr@entry=0x0) at gmessages.c:1058 #3 0x0000000000436c30 in nm_device_release_one_slave (dev=dev@entry=0xd92540, slave=slave@entry=0xdb0e50, configure=configure@entry=1) at devices/nm-device.c:841 #4 0x000000000043a779 in slave_state_changed (slave=0xdb0e50, slave_new_state=NM_DEVICE_STATE_UNMANAGED, slave_old_state=NM_DEVICE_STATE_ACTIVATED, reason=<optimized out>, self=0xd92540) at devices/nm-device.c:1214 #5 0x0000003371805d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76 #6 0x00000033718056bc in ffi_call (cif=cif@entry=0x7fff8b1d3a00, fn=0x43a677 <slave_state_changed>, rvalue=0x7fff8b1d3970, avalue=avalue@entry=0x7fff8b1d38f0) at ../src/x86/ffi64.c:522 #7 0x0000003371c10ad8 in g_cclosure_marshal_generic (closure=0xd76120, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454 #8 0x0000003371c10298 in g_closure_invoke (closure=0xd76120, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fff8b1d3c00, invocation_hint=invocation_hint@entry=0x7fff8b1d3ba0) at gclosure.c:777 #9 0x0000003371c2235d in signal_emit_unlocked_R (node=node@entry=0xd9d850, detail=detail@entry=0, instance=instance@entry=0xdb0e50, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff8b1d3c00) at gsignal.c:3586 #10 0x0000003371c2a0f2 in g_signal_emit_valist (instance=instance@entry=0xdb0e50, signal_id=signal_id@entry=68, detail=detail@entry=0, var_args=var_args@entry=0x7fff8b1d3e38) at gsignal.c:3330 #11 0x0000003371c2a8f8 in g_signal_emit_by_name (instance=instance@entry=0xdb0e50, detailed_signal=detailed_signal@entry=0x4c3ce2 "state-changed") at gsignal.c:3426 #12 0x000000000043754f in _set_state_full (device=device@entry=0xdb0e50, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6689 #13 0x000000000043797c in nm_device_state_changed (device=device@entry=0xdb0e50, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823 #14 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0xdb0e50, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983 #15 0x00000000004799c2 in remove_device (manager=manager@entry=0xd86150, device=0xdb0e50, quitting=quitting@entry=0) at nm-manager.c:769 #16 0x000000000047e3bf in platform_link_cb (platform=<optimized out>, ifindex=35, plink=<optimized out>, change_type=<optimized out>, reason=<optimized out>, user_data=<optimized out>) at nm-manager.c:2123 #17 0x0000003371805d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76 #18 0x00000033718056bc in ffi_call (cif=cif@entry=0x7fff8b1d4320, fn=0x47e34b <platform_link_cb>, rvalue=0x7fff8b1d4290, avalue=avalue@entry=0x7fff8b1d4210) at ../src/x86/ffi64.c:522 #19 0x0000003371c10ad8 in g_cclosure_marshal_generic (closure=0xd32e40, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454 #20 0x0000003371c10298 in g_closure_invoke (closure=0xd32e40, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff8b1d4520, invocation_hint=invocation_hint@entry=0x7fff8b1d44c0) at gclosure.c:777 #21 0x0000003371c2235d in signal_emit_unlocked_R (node=node@entry=0xcf5780, detail=detail@entry=0, instance=instance@entry=0xcf78a0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff8b1d4520) at gsignal.c:3586 #22 0x0000003371c2a0f2 in g_signal_emit_valist (instance=instance@entry=0xcf78a0, signal_id=signal_id@entry=2, detail=detail@entry=0, var_args=var_args@entry=0x7fff8b1d4778) at gsignal.c:3330 #23 0x0000003371c2a8f8 in g_signal_emit_by_name (instance=instance@entry=0xcf78a0, detailed_signal=detailed_signal@entry=0x4b183d "link-changed") at gsignal.c:3426 #24 0x000000000044c6f3 in announce_object (platform=platform@entry=0xcf78a0, object=0xde1720, change_type=change_type@entry=NM_PLATFORM_SIGNAL_REMOVED, reason=reason@entry=NM_PLATFORM_REASON_EXTERNAL) at platform/nm-linux-platform.c:1572 #25 0x000000000044ec07 in event_notification (msg=<optimized out>, user_data=<optimized out>) at platform/nm-linux-platform.c:1886 #26 0x0000003844c1117f in nl_cb_call (msg=<optimized out>, type=<optimized out>, cb=<optimized out>) at ../include/netlink-private/netlink.h:141 #27 recvmsgs (cb=0xcf7240, sk=0xcf7330) at nl.c:952 #28 nl_recvmsgs_report (sk=0xcf7330, cb=0xcf7240) at nl.c:1003 #29 0x0000003844c11549 in nl_recvmsgs (sk=<optimized out>, cb=<optimized out>) at nl.c:1027 #30 0x0000003844c11569 in nl_recvmsgs_default (sk=<optimized out>) at nl.c:1041 #31 0x000000000044e955 in event_handler (channel=<optimized out>, io_condition=<optimized out>, user_data=0xcf78a0) at platform/nm-linux-platform.c:3804 #32 0x0000003370c492a6 in g_main_dispatch (context=0xcf5190) at gmain.c:3066 #33 g_main_context_dispatch (context=context@entry=0xcf5190) at gmain.c:3642 #34 0x0000003370c49628 in g_main_context_iterate (context=0xcf5190, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #35 0x0000003370c49a3a in g_main_loop_run (loop=0xcf4e30) at gmain.c:3907 #36 0x0000000000429f15 in main (argc=1, argv=0x7fff8b1d4f38) at main.c:678 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-23 11:18:45 +02:00
reason = priv->state_reason;
if (priv->state == NM_DEVICE_STATE_FAILED)
reason = NM_DEVICE_STATE_REASON_DEPENDENCY_FAILED;
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_get (nm_device_get_platform (self), priv->ifindex))
device: don't tell the device to unconfigure if it's gone already After the device is unrealized a lot of its properites are reset. Notably, it doesn't have an ifindex anymore so there's nothing to unconfigure really. This makes at least NMDeviceBond unhappy: (bond device with a slave is removed externally) NetworkManager[21022]: <info> (bond0): device state change: activated -> unmanaged (reason 'unmanaged') [100 10 3] NetworkManager[21022]: nm_platform_link_release: assertion 'master > 0' failed Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555557592b1 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd370) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff4ec88c3 in g_logv (log_domain=0x5555557592b1 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd370) at gmessages.c:1046 #1 0x00007ffff4ec8a3f in g_log (log_domain=log_domain@entry=0x5555557592b1 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff4f3673d "%s: assertion '%s' failed") at gmessages.c:1079 #2 0x00007ffff4ec8a79 in g_return_if_fail_warning (log_domain=log_domain@entry=0x5555557592b1 "NetworkManager", pretty_function=pretty_function@entry=0x55555575ea50 <__FUNCTION__.33801> "nm_platform_link_relea8 #3 0x000055555560559a in nm_platform_link_release (self=0x555555a27bb0 [NMLinuxPlatform], master=master@entry=0, slave=slave@entry=3) at platform/nm-platform.c:1326 #4 0x00005555555b506e in release_slave (device=<optimized out>, slave=0x555555b6d770 [NMDeviceEthernet], configure=<optimized out>) at devices/nm-device-bond.c:423 #5 0x00005555555dab7b in nm_device_master_release_one_slave (self=self@entry=0x555555bf0cc0 [NMDeviceBond], slave=0x555555b6d770 [NMDeviceEthernet], configure=configure@entry=1, reason=reason@entry= NM_DEVICE_STATE_REASON_NOW_UNMANAGED) at devices/nm-device.c:1137 #6 0x00005555555dadb6 in nm_device_master_release_slaves (self=self@entry=0x555555bf0cc0 [NMDeviceBond]) at devices/nm-device.c:2344 #7 0x00005555555dd12f in nm_device_cleanup (self=self@entry=0x555555bf0cc0 [NMDeviceBond], reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_UNMANAGED, cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE) at devices/nm-device.c:9133 #8 0x00005555555de3ea in _set_state_full (self=self@entry=0x555555bf0cc0 [NMDeviceBond], state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry= NM_DEVICE_STATE_REASON_NOW_UNMANAGED, quitting=quitting@entry=0) at devices/nm-device.c:9510 #9 0x00005555555dedb7 in nm_device_state_changed (self=self@entry=0x555555bf0cc0 [NMDeviceBond], state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_UNMANAGED) at devices/nm-device.c:9769 #10 0x00005555555e11b4 in nm_device_unrealize (self=self@entry=0x555555bf0cc0 [NMDeviceBond], remove_resources=remove_resources@entry=0, error=error@entry=0x7fffffffd788) at devices/nm-device.c:2062 #11 0x000055555565c9c5 in _platform_link_cb_idle (data=0x555555c6e2b0) at nm-manager.c:2055 #12 0x00007ffff4ec179a in g_main_context_dispatch (context=0x555555a226c0) at gmain.c:3109 #13 0x00007ffff4ec179a in g_main_context_dispatch (context=context@entry=0x555555a226c0) at gmain.c:3708 #14 0x00007ffff4ec1ae8 in g_main_context_iterate (context=0x555555a226c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3779 #15 0x00007ffff4ec1dba in g_main_loop_run (loop=0x555555a22780) at gmain.c:3973 #16 0x00005555555b3e5f in main (argc=1, argv=0x7fffffffdb18) at main.c:488
2015-12-11 17:23:51 +01:00
configure = FALSE;
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
c_list_for_each_safe (iter, safe, &priv->slaves) {
SlaveInfo *info = c_list_entry (iter, SlaveInfo, lst_slave);
core: fix list manipulation when removing multiple slaves nm_device_release_one_slave() may change the list head, but the for loop in nm_device_master_release_slaves() can't handle that. Use a while loop instead.
2013-05-15 14:39:16 -05:00
device: don't tell the device to unconfigure if it's gone already After the device is unrealized a lot of its properites are reset. Notably, it doesn't have an ifindex anymore so there's nothing to unconfigure really. This makes at least NMDeviceBond unhappy: (bond device with a slave is removed externally) NetworkManager[21022]: <info> (bond0): device state change: activated -> unmanaged (reason 'unmanaged') [100 10 3] NetworkManager[21022]: nm_platform_link_release: assertion 'master > 0' failed Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555557592b1 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd370) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff4ec88c3 in g_logv (log_domain=0x5555557592b1 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd370) at gmessages.c:1046 #1 0x00007ffff4ec8a3f in g_log (log_domain=log_domain@entry=0x5555557592b1 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff4f3673d "%s: assertion '%s' failed") at gmessages.c:1079 #2 0x00007ffff4ec8a79 in g_return_if_fail_warning (log_domain=log_domain@entry=0x5555557592b1 "NetworkManager", pretty_function=pretty_function@entry=0x55555575ea50 <__FUNCTION__.33801> "nm_platform_link_relea8 #3 0x000055555560559a in nm_platform_link_release (self=0x555555a27bb0 [NMLinuxPlatform], master=master@entry=0, slave=slave@entry=3) at platform/nm-platform.c:1326 #4 0x00005555555b506e in release_slave (device=<optimized out>, slave=0x555555b6d770 [NMDeviceEthernet], configure=<optimized out>) at devices/nm-device-bond.c:423 #5 0x00005555555dab7b in nm_device_master_release_one_slave (self=self@entry=0x555555bf0cc0 [NMDeviceBond], slave=0x555555b6d770 [NMDeviceEthernet], configure=configure@entry=1, reason=reason@entry= NM_DEVICE_STATE_REASON_NOW_UNMANAGED) at devices/nm-device.c:1137 #6 0x00005555555dadb6 in nm_device_master_release_slaves (self=self@entry=0x555555bf0cc0 [NMDeviceBond]) at devices/nm-device.c:2344 #7 0x00005555555dd12f in nm_device_cleanup (self=self@entry=0x555555bf0cc0 [NMDeviceBond], reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_UNMANAGED, cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE) at devices/nm-device.c:9133 #8 0x00005555555de3ea in _set_state_full (self=self@entry=0x555555bf0cc0 [NMDeviceBond], state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry= NM_DEVICE_STATE_REASON_NOW_UNMANAGED, quitting=quitting@entry=0) at devices/nm-device.c:9510 #9 0x00005555555dedb7 in nm_device_state_changed (self=self@entry=0x555555bf0cc0 [NMDeviceBond], state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_UNMANAGED) at devices/nm-device.c:9769 #10 0x00005555555e11b4 in nm_device_unrealize (self=self@entry=0x555555bf0cc0 [NMDeviceBond], remove_resources=remove_resources@entry=0, error=error@entry=0x7fffffffd788) at devices/nm-device.c:2062 #11 0x000055555565c9c5 in _platform_link_cb_idle (data=0x555555c6e2b0) at nm-manager.c:2055 #12 0x00007ffff4ec179a in g_main_context_dispatch (context=0x555555a226c0) at gmain.c:3109 #13 0x00007ffff4ec179a in g_main_context_dispatch (context=context@entry=0x555555a226c0) at gmain.c:3708 #14 0x00007ffff4ec1ae8 in g_main_context_iterate (context=0x555555a226c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3779 #15 0x00007ffff4ec1dba in g_main_loop_run (loop=0x555555a22780) at gmain.c:3973 #16 0x00005555555b3e5f in main (argc=1, argv=0x7fffffffdb18) at main.c:488
2015-12-11 17:23:51 +01:00
nm_device_master_release_one_slave (self, info->slave, configure, reason);
core: fix list manipulation when removing multiple slaves nm_device_release_one_slave() may change the list head, but the for loop in nm_device_master_release_slaves() can't handle that. Use a while loop instead.
2013-05-15 14:39:16 -05:00
}
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
}
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d core: allow ActiveConnections to be created without a device But it's not easy to do a separate revert of that code due to interdependencies with nm-manager.c. Creating devices when they are defined by a connection also makes makes it possible to require the NMDevice to be present when activating it, which means we can remove a bunch of code from NMManager that had to handle software devices not existing yet at the time of the activation request. But it also means we must be more careful when finding master interfaces during slave activation, since we cannot simply match by interface name alone. Instead we must find the master which matches both the interface name and can control slaves of the type which is being activated.
2014-10-15 21:17:45 -05:00
/**
* nm_device_is_master:
* @self: the device
*
* Returns: %TRUE if the device can have slaves
*/
gboolean
nm_device_is_master (NMDevice *self)
{
device: transform NM_DEVICE_IS_MASTER gobject property to field in NMDeviceClass We don't need this flexibility of having a full fledged GObject property for is-master. The property value only depends on the device's class.
2017-06-01 23:08:30 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
return NM_DEVICE_GET_CLASS (self)->is_master;
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d core: allow ActiveConnections to be created without a device But it's not easy to do a separate revert of that code due to interdependencies with nm-manager.c. Creating devices when they are defined by a connection also makes makes it possible to require the NMDevice to be present when activating it, which means we can remove a bunch of code from NMManager that had to handle software devices not existing yet at the time of the activation request. But it also means we must be more careful when finding master interfaces during slave activation, since we cannot simply match by interface name alone. Instead we must find the master which matches both the interface name and can control slaves of the type which is being activated.
2014-10-15 21:17:45 -05:00
}
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
/**
* nm_device_get_master:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the device
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* If @self has been enslaved by another device, this returns that
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
* device. Otherwise it returns %NULL. (In particular, note that if
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self is in the process of activating as a slave, but has not yet
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
* been enslaved by its master, this will return %NULL.)
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* Returns: (transfer none): @self's master, or %NULL
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
*/
NMDevice *
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_get_master (NMDevice *self)
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
if (priv->is_enslaved) {
g_return_val_if_fail (priv->master, NULL);
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
return priv->master;
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
}
return NULL;
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
}
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
device/trivial: move check_ip_state() upwards
2017-10-23 10:26:27 +02:00
static gboolean
get_ip_config_may_fail (NMDevice *self, int addr_family)
{
NMConnection *connection;
NMSettingIPConfig *s_ip = NULL;
connection = nm_device_get_applied_connection (self);
/* Fail the connection if the failed IP method is required to complete */
switch (addr_family) {
case AF_INET:
s_ip = nm_connection_get_setting_ip4_config (connection);
break;
case AF_INET6:
s_ip = nm_connection_get_setting_ip6_config (connection);
break;
default:
nm_assert_not_reached ();
}
return !s_ip || nm_setting_ip_config_get_may_fail (s_ip);
}
/*
* check_ip_state
*
* Transition the device from IP_CONFIG to the next state according to the
* outcome of IPv4 and IPv6 configuration. @may_fail indicates that we are
* called just after the initial configuration and thus IPv4/IPv6 are allowed to
* fail if the ipvx.may-fail properties say so, because the IP methods couldn't
* even be started.
*/
static void
check_ip_state (NMDevice *self, gboolean may_fail)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
gboolean ip4_disabled = FALSE, ip6_ignore = FALSE;
NMSettingIPConfig *s_ip4, *s_ip6;
NMDeviceState state;
if (nm_device_get_state (self) != NM_DEVICE_STATE_IP_CONFIG)
return;
device: don't progress from ip-config state when we're enslaved We now can be enslaved and have L3 configuration at the same time. This also reduces some unnecessary complexity, because the decision to progress to IP_CHECK or SECONDARIES now happens in a single place, in the check_ip_state() routine.
2017-10-23 11:59:23 +02:00
/* Don't progress into IP_CHECK or SECONDARIES if we're waiting for the
* master to enslave us. */
if ( nm_active_connection_get_master (NM_ACTIVE_CONNECTION (priv->act_request))
&& !priv->is_enslaved)
return;
device/trivial: move check_ip_state() upwards
2017-10-23 10:26:27 +02:00
s_ip4 = (NMSettingIPConfig *) nm_device_get_applied_setting (self, NM_TYPE_SETTING_IP4_CONFIG);
if (s_ip4 && nm_streq0 (nm_setting_ip_config_get_method (s_ip4),
NM_SETTING_IP4_CONFIG_METHOD_DISABLED))
ip4_disabled = TRUE;
s_ip6 = (NMSettingIPConfig *) nm_device_get_applied_setting (self, NM_TYPE_SETTING_IP6_CONFIG);
if (s_ip6 && nm_streq0 (nm_setting_ip_config_get_method (s_ip6),
NM_SETTING_IP6_CONFIG_METHOD_IGNORE))
ip6_ignore = TRUE;
if ( priv->ip4_state == IP_DONE
&& priv->ip6_state == IP_DONE) {
/* Both method completed (or disabled), proceed with activation */
nm_device_state_changed (self, NM_DEVICE_STATE_IP_CHECK, NM_DEVICE_STATE_REASON_NONE);
return;
}
if ( (priv->ip4_state == IP_FAIL || (ip4_disabled && priv->ip4_state == IP_DONE))
&& (priv->ip6_state == IP_FAIL || (ip6_ignore && priv->ip6_state == IP_DONE))) {
/* Either both methods failed, or only one failed and the other is
* disabled */
if (nm_device_sys_iface_state_is_external_or_assume (self)) {
/* We have assumed configuration, but couldn't redo it. No problem,
* move to check state. */
_set_ip_state (self, AF_INET, IP_DONE);
_set_ip_state (self, AF_INET6, IP_DONE);
state = NM_DEVICE_STATE_IP_CHECK;
} else if ( may_fail
&& get_ip_config_may_fail (self, AF_INET)
&& get_ip_config_may_fail (self, AF_INET6)) {
/* Couldn't start either IPv6 and IPv4 autoconfiguration,
* but both are allowed to fail. */
state = NM_DEVICE_STATE_SECONDARIES;
} else {
/* Autoconfiguration attempted without success. */
state = NM_DEVICE_STATE_FAILED;
}
nm_device_state_changed (self,
state,
NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE);
return;
}
/* If a method is still pending but required, wait */
if (priv->ip4_state != IP_DONE && !get_ip_config_may_fail (self, AF_INET))
return;
if (priv->ip6_state != IP_DONE && !get_ip_config_may_fail (self, AF_INET6))
return;
/* If at least a method has completed, proceed with activation */
if ( (priv->ip4_state == IP_DONE && !ip4_disabled)
|| (priv->ip6_state == IP_DONE && !ip6_ignore)) {
nm_device_state_changed (self, NM_DEVICE_STATE_IP_CHECK, NM_DEVICE_STATE_REASON_NONE);
return;
}
}
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
/**
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
* nm_device_slave_notify_enslave:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the slave device
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
* @success: whether the enslaving operation succeeded
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
*
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
* Notifies a slave that either it has been enslaved, or else its master tried
* to enslave it and failed.
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
*/
trivial: fix some prototypes
2013-11-18 12:06:10 -06:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_slave_notify_enslave (NMDevice *self, gboolean success)
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
NMConnection *connection = nm_device_get_applied_connection (self);
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
gboolean activating = (priv->state == NM_DEVICE_STATE_IP_CONFIG);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
g_return_if_fail (priv->master);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
device/trivial: rename fields to have unique names
2015-08-06 14:17:29 +02:00
if (!priv->is_enslaved) {
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
if (success) {
if (activating) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_DEVICE, "Activation: connection '%s' enslaved, continuing activation",
nm_connection_get_id (connection));
} else
_LOGI (LOGD_DEVICE, "enslaved to %s", nm_device_get_iface (priv->master));
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
device/trivial: rename fields to have unique names
2015-08-06 14:17:29 +02:00
priv->is_enslaved = TRUE;
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_MASTER);
_notify (priv->master, PROP_SLAVES);
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
} else if (activating) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_DEVICE, "Activation: connection '%s' could not be enslaved",
nm_connection_get_id (connection));
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
}
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
}
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
if (activating) {
device: set a reason when device enslave fails Otherwise we'd hit an assert and rightly so! Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555556b2f80 "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffcd10) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 g_logv (log_domain=0x5555556b2f80 "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffcd10) at gmessages.c:1046 #1 0x00007ffff4a4ea3f in g_log (log_domain=log_domain@entry=0x5555556b2f80 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7ffff4ac1e4c "%s") at gmessages.c:1079 #2 0x00007ffff4a4ed56 in g_warn_message (domain=domain@entry=0x5555556b2f80 "NetworkManager", file=file@entry=0x5555556aca93 "devices/nm-device.c", line=line@entry=1101, func=func@entry=0x5555556b22e0 <__FUNCTION__.35443> "nm_device_release_one_slave", warnexpr=warnexpr@entry=0x0) at gmessages.c:1112 #3 0x00005555555ba80a in nm_device_release_one_slave (self=self@entry=0x5555559ec4c0, slave=slave@entry=0x5555559f7800, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:1101 #4 0x00005555555c264b in slave_state_changed (slave=0x5555559f7800, slave_new_state=NM_DEVICE_STATE_FAILED, slave_old_state=NM_DEVICE_STATE_IP_CONFIG, reason=NM_DEVICE_STATE_REASON_NONE, self=0x5555559ec4c0) at devices/nm-device.c:1700 #5 0x00007ffff339cdac in ffi_call_unix64 () at ../src/x86/unix64.S:76 #6 0x00007ffff339c6d5 in ffi_call (cif=cif@entry=0x7fffffffd1c0, fn=<optimized out>, rvalue=0x7fffffffd130, avalue=avalue@entry=0x7fffffffd0b0) at ../src/x86/ffi64.c:522 #7 0x00007ffff4d45678 in g_cclosure_marshal_generic (closure=0x5555559b0160, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454 #8 0x00007ffff4d44e38 in g_closure_invoke (closure=0x5555559b0160, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fffffffd3c0, invocation_hint=invocation_hint@entry=0x7fffffffd360) at gclosure.c:768 #9 0x00007ffff4d5675d in signal_emit_unlocked_R (node=node@entry=0x55555598a6f0, detail=detail@entry=0, instance=instance@entry=0x5555559f7800, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd3c0) at gsignal.c:3553 #10 0x00007ffff4d5e4c1 in g_signal_emit_valist (instance=instance@entry=0x5555559f7800, signal_id=signal_id@entry=72, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffd5f8) at gsignal.c:3309 #11 0x00007ffff4d5ecc8 in g_signal_emit_by_name (instance=instance@entry=0x5555559f7800, detailed_signal=detailed_signal@entry=0x5555556c0405 "state-changed") at gsignal.c:3405 #12 0x00005555555bd0e0 in _set_state_full (self=self@entry=0x5555559f7800, state=state@entry=NM_DEVICE_STATE_FAILED, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE, quitting=quitting@entry=0) at devices/nm-device.c:8580 #13 0x00005555555be0e7 in nm_device_state_changed (self=self@entry=0x5555559f7800, state=state@entry=NM_DEVICE_STATE_FAILED, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:8741 #14 0x00005555555c0a45 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8765 #15 0x00007ffff4a4779a in g_main_dispatch (context=0x5555559433c0) at gmain.c:3109 #16 g_main_context_dispatch (context=context@entry=0x5555559433c0) at gmain.c:3708 #17 0x00007ffff4a47ae8 in g_main_context_iterate (context=0x5555559433c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3779 #18 0x00007ffff4a47dba in g_main_loop_run (loop=0x555555943480) at gmain.c:3973 #19 0x000055555559713d in main (argc=1, argv=0x7fffffffdb78) at main.c:512 (gdb)
2015-11-06 14:30:32 +01:00
if (success)
device: don't progress from ip-config state when we're enslaved We now can be enslaved and have L3 configuration at the same time. This also reduces some unnecessary complexity, because the decision to progress to IP_CHECK or SECONDARIES now happens in a single place, in the check_ip_state() routine.
2017-10-23 11:59:23 +02:00
check_ip_state (self, FALSE);
device: set a reason when device enslave fails Otherwise we'd hit an assert and rightly so! Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555556b2f80 "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffcd10) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 g_logv (log_domain=0x5555556b2f80 "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffcd10) at gmessages.c:1046 #1 0x00007ffff4a4ea3f in g_log (log_domain=log_domain@entry=0x5555556b2f80 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7ffff4ac1e4c "%s") at gmessages.c:1079 #2 0x00007ffff4a4ed56 in g_warn_message (domain=domain@entry=0x5555556b2f80 "NetworkManager", file=file@entry=0x5555556aca93 "devices/nm-device.c", line=line@entry=1101, func=func@entry=0x5555556b22e0 <__FUNCTION__.35443> "nm_device_release_one_slave", warnexpr=warnexpr@entry=0x0) at gmessages.c:1112 #3 0x00005555555ba80a in nm_device_release_one_slave (self=self@entry=0x5555559ec4c0, slave=slave@entry=0x5555559f7800, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:1101 #4 0x00005555555c264b in slave_state_changed (slave=0x5555559f7800, slave_new_state=NM_DEVICE_STATE_FAILED, slave_old_state=NM_DEVICE_STATE_IP_CONFIG, reason=NM_DEVICE_STATE_REASON_NONE, self=0x5555559ec4c0) at devices/nm-device.c:1700 #5 0x00007ffff339cdac in ffi_call_unix64 () at ../src/x86/unix64.S:76 #6 0x00007ffff339c6d5 in ffi_call (cif=cif@entry=0x7fffffffd1c0, fn=<optimized out>, rvalue=0x7fffffffd130, avalue=avalue@entry=0x7fffffffd0b0) at ../src/x86/ffi64.c:522 #7 0x00007ffff4d45678 in g_cclosure_marshal_generic (closure=0x5555559b0160, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454 #8 0x00007ffff4d44e38 in g_closure_invoke (closure=0x5555559b0160, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fffffffd3c0, invocation_hint=invocation_hint@entry=0x7fffffffd360) at gclosure.c:768 #9 0x00007ffff4d5675d in signal_emit_unlocked_R (node=node@entry=0x55555598a6f0, detail=detail@entry=0, instance=instance@entry=0x5555559f7800, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd3c0) at gsignal.c:3553 #10 0x00007ffff4d5e4c1 in g_signal_emit_valist (instance=instance@entry=0x5555559f7800, signal_id=signal_id@entry=72, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffd5f8) at gsignal.c:3309 #11 0x00007ffff4d5ecc8 in g_signal_emit_by_name (instance=instance@entry=0x5555559f7800, detailed_signal=detailed_signal@entry=0x5555556c0405 "state-changed") at gsignal.c:3405 #12 0x00005555555bd0e0 in _set_state_full (self=self@entry=0x5555559f7800, state=state@entry=NM_DEVICE_STATE_FAILED, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE, quitting=quitting@entry=0) at devices/nm-device.c:8580 #13 0x00005555555be0e7 in nm_device_state_changed (self=self@entry=0x5555559f7800, state=state@entry=NM_DEVICE_STATE_FAILED, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:8741 #14 0x00005555555c0a45 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8765 #15 0x00007ffff4a4779a in g_main_dispatch (context=0x5555559433c0) at gmain.c:3109 #16 g_main_context_dispatch (context=context@entry=0x5555559433c0) at gmain.c:3708 #17 0x00007ffff4a47ae8 in g_main_context_iterate (context=0x5555559433c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3779 #18 0x00007ffff4a47dba in g_main_loop_run (loop=0x555555943480) at gmain.c:3973 #19 0x000055555559713d in main (argc=1, argv=0x7fffffffdb78) at main.c:512 (gdb)
2015-11-06 14:30:32 +01:00
else
nm_device_queue_state (self, NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_UNKNOWN);
devices: observe externally-caused master/slave changes (rh #1066706) If a link's "master" property changes unexpectedly (ie, from outside NM), update the master and slave NMDevices to reflect it, without making any changes to them.
2014-02-25 16:44:01 -05:00
} else
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_queue_recheck_assume (self);
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
}
core: handle slave deactivation more gracefully Two things: 1) When the slave was deactivated, nm_device_deactivate() runs before the master gets the slave's state-changed signal, and thus priv->master is cleared long before nm_device_notify_enslaved() is called. Which would trigger the g_assert (priv->master). 2) If the slave is already deactivated, there's no point in re-queueing a state change to deactivated. So just assert that priv->master is valid if the slave is going to be enslaved, but if the slave is being released, ignore NULL priv->master which we don't use anyway. Also ignore redundant state changes.
2013-01-17 15:44:30 -06:00
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
/**
* nm_device_slave_notify_release:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the slave device
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
* @reason: the reason associated with the state change
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
*
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
* Notifies a slave that it has been released, and why.
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
*/
trivial: fix some prototypes
2013-11-18 12:06:10 -06:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_slave_notify_release (NMDevice *self, NMDeviceStateReason reason)
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
NMConnection *connection = nm_device_get_applied_connection (self);
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
NMDeviceState new_state;
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
const char *master_status;
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
g_return_if_fail (priv->master);
device: fix disconnecting slave-device when master gets deleted When deleting a master-device either via `nmcli device delete` or `ip link delete`, the slave-device would hang. This seems to be broken for a very long time already. This is due to the following: #0 0x00005555555f548c in nm_device_slave_notify_release (self=0x555555dc1300, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:2175 #1 0x00005555555d6de2 in nm_device_release_one_slave (self=0x555555de3dd0, slave=0x555555dc1300, configure=0, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:1117 #2 0x00005555555f02b7 in device_link_changed (self=0x555555dc1300) at devices/nm-device.c:1460 Previously, nm_device_slave_notify_release() being called with reason "NONE" did not actually transition the device-state, thus keeping the device wrongly in activated state. There were two callers that passed configure=FALSE to nm_device_release_one_slave(), (and thus reason=NONE to nm_device_slave_notify_release()): - (1) device_link_changed(): nm_device_release_one_slave (priv->master, self, FALSE, /*wrong reason NONE*/); - (2) nm_device_removed(): nm_device_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_REMOVED); We should always change the device-state during nm_device_slave_notify_release() regardless of the reason. (2) was added by commit c83b40aca76fc0ed624a6c9e71dbd7b0abfa13f2, later refined by commit 5dd48f7527c67b399ac144f594e035216771d61c. In a way change the second fix to perform some of the configuration (but still not unenslaving the device).
2015-12-03 17:18:50 +01:00
if ( priv->state > NM_DEVICE_STATE_DISCONNECTED
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
&& priv->state <= NM_DEVICE_STATE_ACTIVATED) {
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
switch (nm_device_state_reason_check (reason)) {
case NM_DEVICE_STATE_REASON_DEPENDENCY_FAILED:
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
new_state = NM_DEVICE_STATE_FAILED;
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
master_status = "failed";
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
break;
case NM_DEVICE_STATE_REASON_USER_REQUESTED:
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
new_state = NM_DEVICE_STATE_DEACTIVATING;
master_status = "deactivated by user request";
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
break;
default:
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
new_state = NM_DEVICE_STATE_DISCONNECTED;
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
master_status = "deactivated";
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
break;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
}
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "Activation: connection '%s' master %s",
nm_connection_get_id (connection),
master_status);
devices: when disconnecting master, propagate reason to the slaves When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
2013-12-05 09:13:26 -05:00
device: cancel pending activation when slave is released Since nm_device_slave_notify_release() is called from outside the activation chain of the slave device (it gets called from the master device) there might be pending activation sources scheduled, clear them before queueing a state change.
2016-06-28 14:12:57 +02:00
/* Cancel any pending activation sources */
_cancel_activation (self);
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_queue_state (self, new_state, reason);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
} else
_LOGI (LOGD_DEVICE, "released from master device %s", nm_device_get_iface (priv->master));
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
device/trivial: rename fields to have unique names
2015-08-06 14:17:29 +02:00
if (priv->is_enslaved) {
priv->is_enslaved = FALSE;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_MASTER);
_notify (priv->master, PROP_SLAVES);
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
}
core: move slave handling to device subclasses Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
2012-02-28 18:35:30 -06:00
}
device: Remove unmanaged slaves from master when they disappear We've previously been just watching for state changes into UNMANAGED state. No state change is emitted upon removal of a device which is already unmanaged. https://bugzilla.gnome.org/show_bug.cgi?id=737659
2014-11-16 16:07:22 +01:00
/**
* nm_device_removed:
* @self: the #NMDevice
manager: fix wrongly removing DNS configuration on shutdown When NetworkManager exits, it must preserve the DNS configuration of devices that are left up. Fixes: 9498ea507eb1d5042736c4351337e91b9c13bdf6
2016-04-20 17:46:41 +02:00
* @unconfigure_ip_config: whether to clear the IP config objects
* of the device (provided, it is still not cleared at this point).
device: Remove unmanaged slaves from master when they disappear We've previously been just watching for state changes into UNMANAGED state. No state change is emitted upon removal of a device which is already unmanaged. https://bugzilla.gnome.org/show_bug.cgi?id=737659
2014-11-16 16:07:22 +01:00
*
* Called by the manager when the device was removed. Releases the device from
* the master in case it's enslaved.
*/
void
manager: fix wrongly removing DNS configuration on shutdown When NetworkManager exits, it must preserve the DNS configuration of devices that are left up. Fixes: 9498ea507eb1d5042736c4351337e91b9c13bdf6
2016-04-20 17:46:41 +02:00
nm_device_removed (NMDevice *self, gboolean unconfigure_ip_config)
device: Remove unmanaged slaves from master when they disappear We've previously been just watching for state changes into UNMANAGED state. No state change is emitted upon removal of a device which is already unmanaged. https://bugzilla.gnome.org/show_bug.cgi?id=737659
2014-11-16 16:07:22 +01:00
{
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
NMDevicePrivate *priv;
device: Remove unmanaged slaves from master when they disappear We've previously been just watching for state changes into UNMANAGED state. No state change is emitted upon removal of a device which is already unmanaged. https://bugzilla.gnome.org/show_bug.cgi?id=737659
2014-11-16 16:07:22 +01:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->master) {
device: fix disconnecting slave-device when master gets deleted When deleting a master-device either via `nmcli device delete` or `ip link delete`, the slave-device would hang. This seems to be broken for a very long time already. This is due to the following: #0 0x00005555555f548c in nm_device_slave_notify_release (self=0x555555dc1300, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:2175 #1 0x00005555555d6de2 in nm_device_release_one_slave (self=0x555555de3dd0, slave=0x555555dc1300, configure=0, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:1117 #2 0x00005555555f02b7 in device_link_changed (self=0x555555dc1300) at devices/nm-device.c:1460 Previously, nm_device_slave_notify_release() being called with reason "NONE" did not actually transition the device-state, thus keeping the device wrongly in activated state. There were two callers that passed configure=FALSE to nm_device_release_one_slave(), (and thus reason=NONE to nm_device_slave_notify_release()): - (1) device_link_changed(): nm_device_release_one_slave (priv->master, self, FALSE, /*wrong reason NONE*/); - (2) nm_device_removed(): nm_device_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_REMOVED); We should always change the device-state during nm_device_slave_notify_release() regardless of the reason. (2) was added by commit c83b40aca76fc0ed624a6c9e71dbd7b0abfa13f2, later refined by commit 5dd48f7527c67b399ac144f594e035216771d61c. In a way change the second fix to perform some of the configuration (but still not unenslaving the device).
2015-12-03 17:18:50 +01:00
/* this is called when something externally messes with the slave or during shut-down.
* Release the slave from master, but don't touch the device. */
device/trivial: rename master related function of nm-device We have the master/slave related functions - for master device: - nm_device_master_add_slave() - nm_device_master_release_slaves() - nm_device_release_one_slave() - nm_device_enslave_slave() - for slave device: - nm_device_slave_notify_enslave() - nm_device_slave_notify_release() Rename the two that didn't match the pattern to - nm_device_master_release_one_slave() - nm_device_master_enslave_slave()
2015-08-06 14:37:12 +02:00
nm_device_master_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
device: fix disconnecting slave-device when master gets deleted When deleting a master-device either via `nmcli device delete` or `ip link delete`, the slave-device would hang. This seems to be broken for a very long time already. This is due to the following: #0 0x00005555555f548c in nm_device_slave_notify_release (self=0x555555dc1300, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:2175 #1 0x00005555555d6de2 in nm_device_release_one_slave (self=0x555555de3dd0, slave=0x555555dc1300, configure=0, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:1117 #2 0x00005555555f02b7 in device_link_changed (self=0x555555dc1300) at devices/nm-device.c:1460 Previously, nm_device_slave_notify_release() being called with reason "NONE" did not actually transition the device-state, thus keeping the device wrongly in activated state. There were two callers that passed configure=FALSE to nm_device_release_one_slave(), (and thus reason=NONE to nm_device_slave_notify_release()): - (1) device_link_changed(): nm_device_release_one_slave (priv->master, self, FALSE, /*wrong reason NONE*/); - (2) nm_device_removed(): nm_device_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_REMOVED); We should always change the device-state during nm_device_slave_notify_release() regardless of the reason. (2) was added by commit c83b40aca76fc0ed624a6c9e71dbd7b0abfa13f2, later refined by commit 5dd48f7527c67b399ac144f594e035216771d61c. In a way change the second fix to perform some of the configuration (but still not unenslaving the device).
2015-12-03 17:18:50 +01:00
}
manager: ensure IP config of device is cleared before removal If the manager removes the device, the IP config objects must be cleared. The reason is that NMPolicy registers to the IP config changed signal and passes these object on to NMDnsManager. If the INTERNAL_DEVICE_REMOVED signal is emited with IP configuration object pending, those objects will be leaked. This partly redoes commit f72816bf108cf3fa52ae267e3622a1f19db28b21, which was reverted. Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=764483
2016-04-04 16:58:33 +02:00
manager: fix wrongly removing DNS configuration on shutdown When NetworkManager exits, it must preserve the DNS configuration of devices that are left up. Fixes: 9498ea507eb1d5042736c4351337e91b9c13bdf6
2016-04-20 17:46:41 +02:00
if (!unconfigure_ip_config)
return;
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
nm_device_set_ip4_config (self, NULL, FALSE, NULL);
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
nm_device_set_ip6_config (self, NULL, FALSE);
device: Remove unmanaged slaves from master when they disappear We've previously been just watching for state changes into UNMANAGED state. No state change is emitted upon removal of a device which is already unmanaged. https://bugzilla.gnome.org/show_bug.cgi?id=737659
2014-11-16 16:07:22 +01:00
}
core: move carrier-detect NMDeviceState handling into NMDevice Move some duplicated carrier-handling code into NMDevice (which can introspect itself to see if it's a subclass that has carrier). The "mostly ignore carrier" special handling for bridges and bonds is now also handled as part of the NMDevice-level carrier handling. https://bugzilla.gnome.org/show_bug.cgi?id=688284
2012-11-12 13:29:06 -05:00
static gboolean
device: add flags to nm_device_is_available()
2015-01-20 20:25:25 +01:00
is_available (NMDevice *self, NMDeviceCheckDevAvailableFlags flags)
core: move carrier-detect NMDeviceState handling into NMDevice Move some duplicated carrier-handling code into NMDevice (which can introspect itself to see if it's a subclass that has carrier). The "mostly ignore carrier" special handling for bridges and bonds is now also handled as part of the NMDevice-level carrier handling. https://bugzilla.gnome.org/show_bug.cgi?id=688284
2012-11-12 13:29:06 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
bonding: enslave/release bonding slaves in activation/deactivation Code is written generic enough to allow easy addition of further master/slave relationships such as bridging relations. Signed-off-by: Thomas Graf <tgraf@redhat.com> (whitespace cleanups and libnl compat by dcbw)
2011-10-18 13:48:48 +02:00
device: refactor how master device's set is_available() Previously, master device types like bridge, bond, and team would overwrite is_available() and check_connection_available() and always return TRUE. The device already expresses via nm_device_is_master() that it is of a master kind. Refactor the code, so, instead of having these device types overwrite is_available() and check_connection_available(), let the parents implementation react on nm_device_is_master(). There is no change in behavior at all. Instead, the knowledge how to treat a master device moves from the device implementation to the parent class.
2017-06-02 00:01:26 +02:00
if ( priv->carrier
|| priv->ignore_carrier)
device: implement flag NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER for is_available()
2015-01-20 21:06:31 +01:00
return TRUE;
device: add NM_DEVICE_CHECK_DEV_AVAILABLE_FOR_USER_REQUEST flag This generalizes _NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER.
2015-12-09 12:08:40 +01:00
if (NM_FLAGS_HAS (flags, _NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER))
device: implement flag NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER for is_available()
2015-01-20 21:06:31 +01:00
return TRUE;
device: refactor how master device's set is_available() Previously, master device types like bridge, bond, and team would overwrite is_available() and check_connection_available() and always return TRUE. The device already expresses via nm_device_is_master() that it is of a master kind. Refactor the code, so, instead of having these device types overwrite is_available() and check_connection_available(), let the parents implementation react on nm_device_is_master(). There is no change in behavior at all. Instead, the knowledge how to treat a master device moves from the device implementation to the parent class.
2017-06-02 00:01:26 +02:00
/* master types are always available even without carrier. */
if (nm_device_is_master (self))
return TRUE;
device: implement flag NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER for is_available()
2015-01-20 21:06:31 +01:00
return FALSE;
bonding: enslave/release bonding slaves in activation/deactivation Code is written generic enough to allow easy addition of further master/slave relationships such as bridging relations. Signed-off-by: Thomas Graf <tgraf@redhat.com> (whitespace cleanups and libnl compat by dcbw)
2011-10-18 13:48:48 +02:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: change the rules for ignore-carrier The previous ignore-carrier rules did not work well with dynamic IP (dhcp/slaac) connections. Change the rule so that only static IP connections can be activated when carrier is not present (but both static and dynamic connections will remain up when carrier is lost).
2013-07-12 10:43:45 -04:00
/**
* nm_device_is_available:
* @self: the #NMDevice
device: add flags to nm_device_is_available()
2015-01-20 20:25:25 +01:00
* @flags: additional flags to influence the check. Flags have the
* meaning to increase the availability of a device.
core: change the rules for ignore-carrier The previous ignore-carrier rules did not work well with dynamic IP (dhcp/slaac) connections. Change the rule so that only static IP connections can be activated when carrier is not present (but both static and dynamic connections will remain up when carrier is lost).
2013-07-12 10:43:45 -04:00
*
* Checks if @self would currently be capable of activating a
* connection. In particular, it checks that the device is ready (eg,
* is not missing firmware), that it has carrier (if necessary), and
* that any necessary external software (eg, ModemManager,
* wpa_supplicant) is available.
*
* @self can only be in a state higher than
* %NM_DEVICE_STATE_UNAVAILABLE when nm_device_is_available() returns
* %TRUE. (But note that it can still be %NM_DEVICE_STATE_UNMANAGED
* when it is available.)
*
* Returns: %TRUE or %FALSE
*/
2008-03-07 Dan Williams <dcbw@redhat.com> First pass of multiple active device support. Expect bugs. * src/nm-ip4-config.c src/nm-ip4-config.h - (nm_ip4_config_get_secondary, nm_ip4_config_set_secondary): remove; there are better ways to do this in the named manager * src/nm-device.c src/nm-device.h - (nm_device_can_activate): return whether the device can activate a connection right now; taking into account things like carrier state and rfkill state - (nm_device_get_best_auto_connection): renamed from nm_device_get_best_connection - (real_act_stage4_get_ip4_config): MTU stuff is now handled in the device subclasses themselves, so that each device can override the MTU from it's NMSetting subclass if needed - (nm_device_set_ip4_config): set MTU when setting up routes and stuff in NetworkManagerSystem.c, not here * src/named-manager/nm-named-manager.c src/named-manager/nm-named-manager.h - (nm_named_manager_name_owner_changed, nm_named_manager_dbus_connection_changed): fix for changes to rewrite_resolv_conf() - (compute_nameservers): don't need the NMNamedManager at all, remove from parameter list - (merge_one_ip4_config): new function; merge ip4 configs together - (rewrite_resolv_conf): write out resolv.conf from all the stored ip4 configs; the VPN config takes precedence, then the best device config, then the rest of the configs - (get_domain_for_config): take the NMNamedManager as an argument to check whether the config is the VPN config - (add_ip4_config_to_named): fixups for removal of the 'secondary' attribute from ip4 configs - (add_all_ip4_configs_to_named): add all the configs in priority order - (remove_ip4_config_from_named): fix for changes to get_domain_for_config() - (nm_named_manager_add_ip4_config): assign the config to the right slot based on its type; callers must pass in the type now - (get_last_default_domain): remove, unused - (nm_named_manager_remove_ip4_config): handle config slots correctly * src/nm-device-802-11-wireless.c - (real_can_activate): new function - (real_get_best_auto_connection): renamed from real_get_best_connection - (real_act_stage4_get_ip4_config): handle MTU override * src/nm-device-802-3-ethernet.c - (real_can_activate): new function - (real_get_best_auto_connection): renamed from real_get_best_connection - (real_act_stage4_get_ip4_config): new function; handle MTU override * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_ip4_config_get): don't need to set the 'secondary' attribute on the ip4 config * src/NetworkManagerPolicy.c - (nm_policy_auto_get_best_device): remove - (nm_policy_device_change_check): remove - (update_default_route): new function; set the default route via the specified device - (get_device_priority): new function; return the priority number of a device type WRT which one should have the default route. Order is (highest to lowest) wired, wireless, GSM, CDMA. - (update_routing_and_dns): new function; determine which device should have the default route, then update the routing table and DNS - (maybe_auto_activate_device): new function; if a device is now available for activation, find out what connection it would like to activate and do it - (schedule_activate_check): new function; if a device can be activated now, schedule the activation. Each device may have only one pending activation at a given time. - (device_state_changed): if activation was canceled, try again, possibly with another connection; if the device was activated, update routing and DNS; if the device was deactivated, try again with another connection - (device_carrier_changed): if there is no carrier, deactivate the device; otherwise schedule an activation check for the device - (wireless_networks_changed): schedule an activation check for the device - (device_added): keep track of the signal handler IDs so they can be removed when the device goes away - (device_removed): remove any signal handlers that might be attached to the device; update routing and DNS - (schedule_activate_all): new function - (connections_added, connection_added, connection_updated): when connections change, schedule all devices for an activation check - (connection_removed): when a device is deactivated because its connection was removed, schedule another activation check for it - (nm_policy_destroy): destroy pending activations and disconnect all device signal handlers * src/nm-manager.c - (nm_manager_activate_device): if the device was already actived, deactivate it - (deactivate_old_device): remove - (connection_added_default_handler, impl_manager_activate_device): don't deactivate other devices when activating this one * src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerArch.c src/backends/NetworkManagerSuSE.c src/backends/NetworkManagerDebian.c - (nm_system_get_mtu): remove; MTU should be provided through the distro's system settings service plugin instead - (nm_system_device_add_default_route_via_device): remove - (nm_system_device_add_default_route_via_device_with_iface): remove - (nm_system_device_replace_default_route): new function; call generic implementation * src/backends/NetworkManagerGeneric.c src/backends/NetworkManagerGeneric.h - (nm_generic_device_add_default_route_via_device, nm_generic_device_add_default_route_via_device_with_iface): remove - (nm_generic_device_replace_default_route): replace the default route with the given route via some gateway * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_from_ip4_config): let the policy handle updates to routing and DNS; but set the MTU here - (nm_system_vpn_device_set_from_ip4_config): set the route with the ip_iface of the active device; use the standard MTU setting function - (nm_system_set_mtu): remove - (nm_system_device_set_mtu): consolidate MTU setting code in one place git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3391 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-07 19:41:32 +00:00
gboolean
device: add flags to nm_device_is_available()
2015-01-20 20:25:25 +01:00
nm_device_is_available (NMDevice *self, NMDeviceCheckDevAvailableFlags flags)
2008-03-07 Dan Williams <dcbw@redhat.com> First pass of multiple active device support. Expect bugs. * src/nm-ip4-config.c src/nm-ip4-config.h - (nm_ip4_config_get_secondary, nm_ip4_config_set_secondary): remove; there are better ways to do this in the named manager * src/nm-device.c src/nm-device.h - (nm_device_can_activate): return whether the device can activate a connection right now; taking into account things like carrier state and rfkill state - (nm_device_get_best_auto_connection): renamed from nm_device_get_best_connection - (real_act_stage4_get_ip4_config): MTU stuff is now handled in the device subclasses themselves, so that each device can override the MTU from it's NMSetting subclass if needed - (nm_device_set_ip4_config): set MTU when setting up routes and stuff in NetworkManagerSystem.c, not here * src/named-manager/nm-named-manager.c src/named-manager/nm-named-manager.h - (nm_named_manager_name_owner_changed, nm_named_manager_dbus_connection_changed): fix for changes to rewrite_resolv_conf() - (compute_nameservers): don't need the NMNamedManager at all, remove from parameter list - (merge_one_ip4_config): new function; merge ip4 configs together - (rewrite_resolv_conf): write out resolv.conf from all the stored ip4 configs; the VPN config takes precedence, then the best device config, then the rest of the configs - (get_domain_for_config): take the NMNamedManager as an argument to check whether the config is the VPN config - (add_ip4_config_to_named): fixups for removal of the 'secondary' attribute from ip4 configs - (add_all_ip4_configs_to_named): add all the configs in priority order - (remove_ip4_config_from_named): fix for changes to get_domain_for_config() - (nm_named_manager_add_ip4_config): assign the config to the right slot based on its type; callers must pass in the type now - (get_last_default_domain): remove, unused - (nm_named_manager_remove_ip4_config): handle config slots correctly * src/nm-device-802-11-wireless.c - (real_can_activate): new function - (real_get_best_auto_connection): renamed from real_get_best_connection - (real_act_stage4_get_ip4_config): handle MTU override * src/nm-device-802-3-ethernet.c - (real_can_activate): new function - (real_get_best_auto_connection): renamed from real_get_best_connection - (real_act_stage4_get_ip4_config): new function; handle MTU override * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_ip4_config_get): don't need to set the 'secondary' attribute on the ip4 config * src/NetworkManagerPolicy.c - (nm_policy_auto_get_best_device): remove - (nm_policy_device_change_check): remove - (update_default_route): new function; set the default route via the specified device - (get_device_priority): new function; return the priority number of a device type WRT which one should have the default route. Order is (highest to lowest) wired, wireless, GSM, CDMA. - (update_routing_and_dns): new function; determine which device should have the default route, then update the routing table and DNS - (maybe_auto_activate_device): new function; if a device is now available for activation, find out what connection it would like to activate and do it - (schedule_activate_check): new function; if a device can be activated now, schedule the activation. Each device may have only one pending activation at a given time. - (device_state_changed): if activation was canceled, try again, possibly with another connection; if the device was activated, update routing and DNS; if the device was deactivated, try again with another connection - (device_carrier_changed): if there is no carrier, deactivate the device; otherwise schedule an activation check for the device - (wireless_networks_changed): schedule an activation check for the device - (device_added): keep track of the signal handler IDs so they can be removed when the device goes away - (device_removed): remove any signal handlers that might be attached to the device; update routing and DNS - (schedule_activate_all): new function - (connections_added, connection_added, connection_updated): when connections change, schedule all devices for an activation check - (connection_removed): when a device is deactivated because its connection was removed, schedule another activation check for it - (nm_policy_destroy): destroy pending activations and disconnect all device signal handlers * src/nm-manager.c - (nm_manager_activate_device): if the device was already actived, deactivate it - (deactivate_old_device): remove - (connection_added_default_handler, impl_manager_activate_device): don't deactivate other devices when activating this one * src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerArch.c src/backends/NetworkManagerSuSE.c src/backends/NetworkManagerDebian.c - (nm_system_get_mtu): remove; MTU should be provided through the distro's system settings service plugin instead - (nm_system_device_add_default_route_via_device): remove - (nm_system_device_add_default_route_via_device_with_iface): remove - (nm_system_device_replace_default_route): new function; call generic implementation * src/backends/NetworkManagerGeneric.c src/backends/NetworkManagerGeneric.h - (nm_generic_device_add_default_route_via_device, nm_generic_device_add_default_route_via_device_with_iface): remove - (nm_generic_device_replace_default_route): replace the default route with the given route via some gateway * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_from_ip4_config): let the policy handle updates to routing and DNS; but set the MTU here - (nm_system_vpn_device_set_from_ip4_config): set the route with the ip_iface of the active device; use the standard MTU setting function - (nm_system_set_mtu): remove - (nm_system_device_set_mtu): consolidate MTU setting code in one place git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3391 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-07 19:41:32 +00:00
{
core/libnm-glib: implement better missing firmware support (rh #594578) Track missing firmware and ensure the device can't be used when firmware is missing. Add a property for missing firmware so that clients can do something intelligent with this information.
2010-05-25 10:52:25 -07:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->firmware_missing)
return FALSE;
device: add flags to nm_device_is_available()
2015-01-20 20:25:25 +01:00
return NM_DEVICE_GET_CLASS (self)->is_available (self, flags);
2008-03-07 Dan Williams <dcbw@redhat.com> First pass of multiple active device support. Expect bugs. * src/nm-ip4-config.c src/nm-ip4-config.h - (nm_ip4_config_get_secondary, nm_ip4_config_set_secondary): remove; there are better ways to do this in the named manager * src/nm-device.c src/nm-device.h - (nm_device_can_activate): return whether the device can activate a connection right now; taking into account things like carrier state and rfkill state - (nm_device_get_best_auto_connection): renamed from nm_device_get_best_connection - (real_act_stage4_get_ip4_config): MTU stuff is now handled in the device subclasses themselves, so that each device can override the MTU from it's NMSetting subclass if needed - (nm_device_set_ip4_config): set MTU when setting up routes and stuff in NetworkManagerSystem.c, not here * src/named-manager/nm-named-manager.c src/named-manager/nm-named-manager.h - (nm_named_manager_name_owner_changed, nm_named_manager_dbus_connection_changed): fix for changes to rewrite_resolv_conf() - (compute_nameservers): don't need the NMNamedManager at all, remove from parameter list - (merge_one_ip4_config): new function; merge ip4 configs together - (rewrite_resolv_conf): write out resolv.conf from all the stored ip4 configs; the VPN config takes precedence, then the best device config, then the rest of the configs - (get_domain_for_config): take the NMNamedManager as an argument to check whether the config is the VPN config - (add_ip4_config_to_named): fixups for removal of the 'secondary' attribute from ip4 configs - (add_all_ip4_configs_to_named): add all the configs in priority order - (remove_ip4_config_from_named): fix for changes to get_domain_for_config() - (nm_named_manager_add_ip4_config): assign the config to the right slot based on its type; callers must pass in the type now - (get_last_default_domain): remove, unused - (nm_named_manager_remove_ip4_config): handle config slots correctly * src/nm-device-802-11-wireless.c - (real_can_activate): new function - (real_get_best_auto_connection): renamed from real_get_best_connection - (real_act_stage4_get_ip4_config): handle MTU override * src/nm-device-802-3-ethernet.c - (real_can_activate): new function - (real_get_best_auto_connection): renamed from real_get_best_connection - (real_act_stage4_get_ip4_config): new function; handle MTU override * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_ip4_config_get): don't need to set the 'secondary' attribute on the ip4 config * src/NetworkManagerPolicy.c - (nm_policy_auto_get_best_device): remove - (nm_policy_device_change_check): remove - (update_default_route): new function; set the default route via the specified device - (get_device_priority): new function; return the priority number of a device type WRT which one should have the default route. Order is (highest to lowest) wired, wireless, GSM, CDMA. - (update_routing_and_dns): new function; determine which device should have the default route, then update the routing table and DNS - (maybe_auto_activate_device): new function; if a device is now available for activation, find out what connection it would like to activate and do it - (schedule_activate_check): new function; if a device can be activated now, schedule the activation. Each device may have only one pending activation at a given time. - (device_state_changed): if activation was canceled, try again, possibly with another connection; if the device was activated, update routing and DNS; if the device was deactivated, try again with another connection - (device_carrier_changed): if there is no carrier, deactivate the device; otherwise schedule an activation check for the device - (wireless_networks_changed): schedule an activation check for the device - (device_added): keep track of the signal handler IDs so they can be removed when the device goes away - (device_removed): remove any signal handlers that might be attached to the device; update routing and DNS - (schedule_activate_all): new function - (connections_added, connection_added, connection_updated): when connections change, schedule all devices for an activation check - (connection_removed): when a device is deactivated because its connection was removed, schedule another activation check for it - (nm_policy_destroy): destroy pending activations and disconnect all device signal handlers * src/nm-manager.c - (nm_manager_activate_device): if the device was already actived, deactivate it - (deactivate_old_device): remove - (connection_added_default_handler, impl_manager_activate_device): don't deactivate other devices when activating this one * src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerArch.c src/backends/NetworkManagerSuSE.c src/backends/NetworkManagerDebian.c - (nm_system_get_mtu): remove; MTU should be provided through the distro's system settings service plugin instead - (nm_system_device_add_default_route_via_device): remove - (nm_system_device_add_default_route_via_device_with_iface): remove - (nm_system_device_replace_default_route): new function; call generic implementation * src/backends/NetworkManagerGeneric.c src/backends/NetworkManagerGeneric.h - (nm_generic_device_add_default_route_via_device, nm_generic_device_add_default_route_via_device_with_iface): remove - (nm_generic_device_replace_default_route): replace the default route with the given route via some gateway * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_from_ip4_config): let the policy handle updates to routing and DNS; but set the MTU here - (nm_system_vpn_device_set_from_ip4_config): set the route with the ip_iface of the active device; use the standard MTU setting function - (nm_system_set_mtu): remove - (nm_system_device_set_mtu): consolidate MTU setting code in one place git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3391 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-07 19:41:32 +00:00
}
device: handle default for unset ignore-carrier option depending on device Currently, device types like Bond hack around ignore-carrier setting, as they always want to ignore-carrier. Prepare so that also for such master types, we rely and honor the ignore-carrier setting better. In the next commit, bond, bridge and team devices they will get ignore-carrier turned on by default.
2017-06-01 22:38:51 +02:00
gboolean
nm_device_ignore_carrier_by_default (NMDevice *self)
{
device: handle carrier changes for master device differently For master devices, instead of ignoring loss of carrier entirely, handle it. First of all, master devices are now by default ignore-carrier=yes. That means, without explict user configuration in NetworkManager.conf, the previous behavior in carrier_changed() does not change. If the user decides to configure the master device like [device-with-carrier] match-device=type:bond,type:bridge,type:team ignore-carrier=no then, master device will disconnect on carrier loss like regular devices. https://github.com/NetworkManager/NetworkManager/pull/18 Co-authored-by: Thomas Haller <thaller@redhat.com>
2017-06-01 23:57:03 +02:00
/* master types ignore-carrier by default. */
return nm_device_is_master (self);
device: handle default for unset ignore-carrier option depending on device Currently, device types like Bond hack around ignore-carrier setting, as they always want to ignore-carrier. Prepare so that also for such master types, we rely and honor the ignore-carrier setting better. In the next commit, bond, bridge and team devices they will get ignore-carrier turned on by default.
2017-06-01 22:38:51 +02:00
}
core: move nm_device_interface_get_enabled() to nm-device.c
2011-11-17 23:28:30 -06:00
gboolean
nm_device_get_enabled (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
if (NM_DEVICE_GET_CLASS (self)->get_enabled)
return NM_DEVICE_GET_CLASS (self)->get_enabled (self);
return TRUE;
}
core: move nm_device_interface_set_enabled() to nm-device.c
2011-11-17 23:38:08 -06:00
void
nm_device_set_enabled (NMDevice *self, gboolean enabled)
{
g_return_if_fail (NM_IS_DEVICE (self));
if (NM_DEVICE_GET_CLASS (self)->set_enabled)
NM_DEVICE_GET_CLASS (self)->set_enabled (self, enabled);
}
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
NM_UTILS_FLAGS2STR_DEFINE_STATIC (_autoconnect_blocked_flags_to_string, NMDeviceAutoconnectBlockedFlags,
device: improve tracking autoconnect-blocked flags of NMDevice - split NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN in two parts: "wrong-pin" and "manual-disconnect". Setting/unsetting them should be tracked differently, as their reason differs. - no longer initialize/clear the autoconnect-blocked reasons during realize/unrealize of the device. Instead, initialize it once when the object gets created (nm_device_init()), and keep the settings beyond unrealize/realize cycles. This only matters for software devices, as regular devices get deleted after unrealizing once. But for software devices it is essential, because we don't want to forget the autoconnect settings of the device instance. - drop verbose logging about blocking autoconnect due to failed pin. We already log changes to autoconnect-blocked flags with TRACE level. An additional message about this particular issue seems not necessary at INFO level. - in NMManager's do_sleep_wake(), no longer block autoconnect for devices during sleep. We already unmanage the device, which is a far more effective measure to prevent activation. We should not also block autoconnect.
2017-11-07 12:36:17 +01:00
NM_UTILS_FLAGS2STR (NM_DEVICE_AUTOCONNECT_BLOCKED_NONE, "none"),
NM_UTILS_FLAGS2STR (NM_DEVICE_AUTOCONNECT_BLOCKED_USER, "user"),
NM_UTILS_FLAGS2STR (NM_DEVICE_AUTOCONNECT_BLOCKED_WRONG_PIN, "wrong-pin"),
NM_UTILS_FLAGS2STR (NM_DEVICE_AUTOCONNECT_BLOCKED_MANUAL_DISCONNECT, "manual-disconnect"),
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
);
NMDeviceAutoconnectBlockedFlags
nm_device_autoconnect_blocked_get (NMDevice *self, NMDeviceAutoconnectBlockedFlags mask)
core: clean up per-device rfkill handling Add an accessor for device rfkill type and use that instead of GObject properties, and also use that accessor when claiming a new device instead of checking NM_IS_DEVICE_xxxx(). Allows us to move one step closer to making WiMAX a plugin.
2011-11-18 12:02:58 -06:00
{
device: separately handle NMDevice's autoconnect by user and internal decision The NMDevice's autoconnect property is settable via D-Bus and is is also modified by internal decision, like when no PIN is available. Certain internal actions cause clearing the internal autoconnect flag, but they should not override the user desicion. For example, when NM awaks from sleep it would reenable autoconnect, but it should not reenable it for devices where the user explicitly said that autoconnect is to be disabled. Similarly, activating a device alone is not yet an instruction to re-enable autoconnect. If the user consciously disables autoconnect, it should stay enabled. On the other hand, activating a device should reenable autoconnect if it was blocked by internal decision. We need to track these two flags separately, and set them accordingly.
2017-02-14 13:57:57 +01:00
NMDevicePrivate *priv;
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
core: clean up per-device rfkill handling Add an accessor for device rfkill type and use that instead of GObject properties, and also use that accessor when claiming a new device instead of checking NM_IS_DEVICE_xxxx(). Allows us to move one step closer to making WiMAX a plugin.
2011-11-18 12:02:58 -06:00
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
if (mask == 0)
mask = NM_DEVICE_AUTOCONNECT_BLOCKED_ALL;
device: separately handle NMDevice's autoconnect by user and internal decision The NMDevice's autoconnect property is settable via D-Bus and is is also modified by internal decision, like when no PIN is available. Certain internal actions cause clearing the internal autoconnect flag, but they should not override the user desicion. For example, when NM awaks from sleep it would reenable autoconnect, but it should not reenable it for devices where the user explicitly said that autoconnect is to be disabled. Similarly, activating a device alone is not yet an instruction to re-enable autoconnect. If the user consciously disables autoconnect, it should stay enabled. On the other hand, activating a device should reenable autoconnect if it was blocked by internal decision. We need to track these two flags separately, and set them accordingly.
2017-02-14 13:57:57 +01:00
priv = NM_DEVICE_GET_PRIVATE (self);
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
return priv->autoconnect_blocked_flags & mask;
core: clean up per-device rfkill handling Add an accessor for device rfkill type and use that instead of GObject properties, and also use that accessor when claiming a new device instead of checking NM_IS_DEVICE_xxxx(). Allows us to move one step closer to making WiMAX a plugin.
2011-11-18 12:02:58 -06:00
}
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
void
nm_device_autoconnect_blocked_set_full (NMDevice *self, NMDeviceAutoconnectBlockedFlags mask, NMDeviceAutoconnectBlockedFlags value)
core: autoconnect fixes for default-unmanaged devices and property notification Previously the only thing preventing default-unmanaged devices from being auto-activated was luck and the fact that they didn't have any available connections when in the UNMANAGED state. That's no longer true, so we must be more explicit about their behavior. Furthermore it makes no sense to allow default-unmanaged devices to set priv->autoconnect=TRUE since that is never supposed to happen, so enforce that both in NM itself and if the change request comes in over the D-Bus interface. Lastly, internal priv->autoconnect=TRUE changes never emitted a property change notification, meaning the NMPolicy would never schedule an autoconnect check if the device's priv->autoconnect was set to TRUE as a result of re-activating or waking from sleep.
2014-10-23 14:57:22 -05:00
{
NMDevicePrivate *priv;
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
gboolean changed;
char buf1[128], buf2[128];
core: autoconnect fixes for default-unmanaged devices and property notification Previously the only thing preventing default-unmanaged devices from being auto-activated was luck and the fact that they didn't have any available connections when in the UNMANAGED state. That's no longer true, so we must be more explicit about their behavior. Furthermore it makes no sense to allow default-unmanaged devices to set priv->autoconnect=TRUE since that is never supposed to happen, so enforce that both in NM itself and if the change request comes in over the D-Bus interface. Lastly, internal priv->autoconnect=TRUE changes never emitted a property change notification, meaning the NMPolicy would never schedule an autoconnect check if the device's priv->autoconnect was set to TRUE as a result of re-activating or waking from sleep.
2014-10-23 14:57:22 -05:00
g_return_if_fail (NM_IS_DEVICE (self));
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
nm_assert (mask);
nm_assert (!NM_FLAGS_ANY (mask, ~NM_DEVICE_AUTOCONNECT_BLOCKED_ALL));
nm_assert (!NM_FLAGS_ANY (value, ~mask));
core: autoconnect fixes for default-unmanaged devices and property notification Previously the only thing preventing default-unmanaged devices from being auto-activated was luck and the fact that they didn't have any available connections when in the UNMANAGED state. That's no longer true, so we must be more explicit about their behavior. Furthermore it makes no sense to allow default-unmanaged devices to set priv->autoconnect=TRUE since that is never supposed to happen, so enforce that both in NM itself and if the change request comes in over the D-Bus interface. Lastly, internal priv->autoconnect=TRUE changes never emitted a property change notification, meaning the NMPolicy would never schedule an autoconnect check if the device's priv->autoconnect was set to TRUE as a result of re-activating or waking from sleep.
2014-10-23 14:57:22 -05:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
device: separately handle NMDevice's autoconnect by user and internal decision The NMDevice's autoconnect property is settable via D-Bus and is is also modified by internal decision, like when no PIN is available. Certain internal actions cause clearing the internal autoconnect flag, but they should not override the user desicion. For example, when NM awaks from sleep it would reenable autoconnect, but it should not reenable it for devices where the user explicitly said that autoconnect is to be disabled. Similarly, activating a device alone is not yet an instruction to re-enable autoconnect. If the user consciously disables autoconnect, it should stay enabled. On the other hand, activating a device should reenable autoconnect if it was blocked by internal decision. We need to track these two flags separately, and set them accordingly.
2017-02-14 13:57:57 +01:00
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
value = (priv->autoconnect_blocked_flags & ~mask) | (mask & value);
if (value == priv->autoconnect_blocked_flags)
return;
device: separately handle NMDevice's autoconnect by user and internal decision The NMDevice's autoconnect property is settable via D-Bus and is is also modified by internal decision, like when no PIN is available. Certain internal actions cause clearing the internal autoconnect flag, but they should not override the user desicion. For example, when NM awaks from sleep it would reenable autoconnect, but it should not reenable it for devices where the user explicitly said that autoconnect is to be disabled. Similarly, activating a device alone is not yet an instruction to re-enable autoconnect. If the user consciously disables autoconnect, it should stay enabled. On the other hand, activating a device should reenable autoconnect if it was blocked by internal decision. We need to track these two flags separately, and set them accordingly.
2017-02-14 13:57:57 +01:00
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
changed = ((!value) != (!priv->autoconnect_blocked_flags));
device: separately handle NMDevice's autoconnect by user and internal decision The NMDevice's autoconnect property is settable via D-Bus and is is also modified by internal decision, like when no PIN is available. Certain internal actions cause clearing the internal autoconnect flag, but they should not override the user desicion. For example, when NM awaks from sleep it would reenable autoconnect, but it should not reenable it for devices where the user explicitly said that autoconnect is to be disabled. Similarly, activating a device alone is not yet an instruction to re-enable autoconnect. If the user consciously disables autoconnect, it should stay enabled. On the other hand, activating a device should reenable autoconnect if it was blocked by internal decision. We need to track these two flags separately, and set them accordingly.
2017-02-14 13:57:57 +01:00
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
_LOGT (LOGD_DEVICE, "autoconnect-blocked: set \"%s\" (was \"%s\")",
_autoconnect_blocked_flags_to_string (value, buf1, sizeof (buf1)),
_autoconnect_blocked_flags_to_string (priv->autoconnect_blocked_flags, buf2, sizeof (buf2)));
priv->autoconnect_blocked_flags = value;
nm_assert (priv->autoconnect_blocked_flags == value);
if (changed)
_notify (self, PROP_AUTOCONNECT);
core: autoconnect fixes for default-unmanaged devices and property notification Previously the only thing preventing default-unmanaged devices from being auto-activated was luck and the fact that they didn't have any available connections when in the UNMANAGED state. That's no longer true, so we must be more explicit about their behavior. Furthermore it makes no sense to allow default-unmanaged devices to set priv->autoconnect=TRUE since that is never supposed to happen, so enforce that both in NM itself and if the change request comes in over the D-Bus interface. Lastly, internal priv->autoconnect=TRUE changes never emitted a property change notification, meaning the NMPolicy would never schedule an autoconnect check if the device's priv->autoconnect was set to TRUE as a result of re-activating or waking from sleep.
2014-10-23 14:57:22 -05:00
}
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
static gboolean
autoconnect_allowed_accumulator (GSignalInvocationHint *ihint,
GValue *return_accu,
const GValue *handler_return, gpointer data)
{
if (!g_value_get_boolean (handler_return))
g_value_set_boolean (return_accu, FALSE);
return TRUE;
}
core: autoconnect fixes for default-unmanaged devices and property notification Previously the only thing preventing default-unmanaged devices from being auto-activated was luck and the fact that they didn't have any available connections when in the UNMANAGED state. That's no longer true, so we must be more explicit about their behavior. Furthermore it makes no sense to allow default-unmanaged devices to set priv->autoconnect=TRUE since that is never supposed to happen, so enforce that both in NM itself and if the change request comes in over the D-Bus interface. Lastly, internal priv->autoconnect=TRUE changes never emitted a property change notification, meaning the NMPolicy would never schedule an autoconnect check if the device's priv->autoconnect was set to TRUE as a result of re-activating or waking from sleep.
2014-10-23 14:57:22 -05:00
/**
* nm_device_autoconnect_allowed:
* @self: the #NMDevice
*
* Returns: %TRUE if the device can be auto-connected immediately, taking
* transient conditions into account (like companion devices that may wish to
* block autoconnect for a time).
*/
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
gboolean
nm_device_autoconnect_allowed (NMDevice *self)
{
core: implement manual disconnect feature In the past networkmanager did not allow to manually disconnect devices. Manually disconnected devices will not be automatically reconnected until one of the following events occur: 1. user activates a connection for the currently disconnected device 2. network manager awakes from hibernate/suspend 3. network manager is restarted (e.g. reboot) Add a Disconnect method to generic NMDevice dbus interface; set a new private autoconnect_inhibit flag if Disconnect method is called through dbus. Based on this auto activation for devices gets inhibited until one of the above events occur.
2009-09-16 13:18:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: add get_autoconnect_allowed() virtual function It allows derived classes to override the autoconnect-allowed state. We already have - NM_DEVICE_AUTOCONNECT property, which is two parts: - NMDevicePrivate::autoconnect_user, which is settable via D-Bus by the use, to allow the device to autoconnect. - NMDevicePrivate::autoconnect_intern, which is set by internal decision. - NM_DEVICE_AUTOCONNECT_ALLOWED signal, where other devices can subscribe to block autoconnect. Currently that is only used by NMDeviceOlpcMesh. These two make up for nm_device_autoconnect_allowed(). Add another way to allow derived classes to disable autoconnect temporarily. This could also be achieved by having the device subscribe to NM_DEVICE_AUTOCONNECT_ALLOWED of self, or by adding a signal slot. But a plain function pointer seems easier.
2017-02-14 12:45:38 +01:00
NMDeviceClass *klass = NM_DEVICE_GET_CLASS (self);
all: use G_VALUE_INIT to initialize GValue variables It makes the initializations more explicit. G_VALUE_INIT is available since glib 2.30, and NM now require glib >= 2.32
2013-03-22 10:49:19 +01:00
GValue instance = G_VALUE_INIT;
GValue retval = G_VALUE_INIT;
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
if (nm_device_autoconnect_blocked_get (self, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
device: drop stub implementation of get_autoconnect_allowed() in NMDevice
2017-11-02 16:00:41 +01:00
return FALSE;
if ( klass->get_autoconnect_allowed
&& !klass->get_autoconnect_allowed (self))
device: the unrealized devices can attempt to autoconnect
2016-01-13 17:49:35 +01:00
return FALSE;
device: move nm_device_get_enabled() from schedule_activate_check() to nm_device_autoconnect_allowed()
2017-11-02 16:33:30 +01:00
if (!nm_device_get_enabled (self))
return FALSE;
device: minor refactoring of condition in nm_device_autoconnect_allowed() Makes it clearer what is happening (to me).
2017-11-08 11:42:50 +01:00
if (nm_device_is_real (self)) {
if (priv->state < NM_DEVICE_STATE_DISCONNECTED)
return FALSE;
} else {
/* Unrealized devices can always autoconnect. */
}
core: autoconnect fixes for default-unmanaged devices and property notification Previously the only thing preventing default-unmanaged devices from being auto-activated was luck and the fact that they didn't have any available connections when in the UNMANAGED state. That's no longer true, so we must be more explicit about their behavior. Furthermore it makes no sense to allow default-unmanaged devices to set priv->autoconnect=TRUE since that is never supposed to happen, so enforce that both in NM itself and if the change request comes in over the D-Bus interface. Lastly, internal priv->autoconnect=TRUE changes never emitted a property change notification, meaning the NMPolicy would never schedule an autoconnect check if the device's priv->autoconnect was set to TRUE as a result of re-activating or waking from sleep.
2014-10-23 14:57:22 -05:00
/* The 'autoconnect-allowed' signal is emitted on a device to allow
* other listeners to block autoconnect on the device if they wish.
* This is mainly used by the OLPC Mesh devices to block autoconnect
* on their companion WiFi device as they share radio resources and
* cannot be connected at the same time.
*/
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
g_value_init (&instance, G_TYPE_OBJECT);
core: minor cleanup to release GValue for G_TYPE_OBJECT Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-05-05 20:58:27 +02:00
g_value_set_object (&instance, self);
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
g_value_init (&retval, G_TYPE_BOOLEAN);
device: trivial: streamline nm_device_autoconnect_allowed() The function returns early when autoconnect is off, so there's no reason to branch for that case below. The signal is only generated for autoconnect=true.
2016-01-13 17:47:32 +01:00
g_value_set_boolean (&retval, TRUE);
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
/* Use g_signal_emitv() rather than g_signal_emit() to avoid the return
* value being changed if no handlers are connected */
g_signal_emitv (&instance, signals[AUTOCONNECT_ALLOWED], 0, &retval);
core: minor cleanup to release GValue for G_TYPE_OBJECT Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-05-05 20:58:27 +02:00
g_value_unset (&instance);
device: trivial: streamline nm_device_autoconnect_allowed() The function returns early when autoconnect is off, so there's no reason to branch for that case below. The signal is only generated for autoconnect=true.
2016-01-13 17:47:32 +01:00
core: allow devices to suppress other device's autoconnect This allows a device (or a companion) to signal that it is not a good time for a specific device to autoconnect to a network. The OLPC mesh device will use this to prevent automatic connection to WLAN networks while the mesh device is active.
2009-07-15 17:22:10 -04:00
return g_value_get_boolean (&retval);
}
core: simplify nm_device_get_best_auto_connection() As with the other connection-matching methods, move the loop and the device-independent bits into NMDevice. By reusing nm_device_check_connection_compatible(), this means that most device types now no longer need any type-specific code for this. https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-03-06 16:16:54 -05:00
static gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
can_auto_connect (NMDevice *self,
core: simplify nm_device_get_best_auto_connection() As with the other connection-matching methods, move the loop and the device-independent bits into NMDevice. By reusing nm_device_check_connection_compatible(), this means that most device types now no longer need any type-specific code for this. https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-03-06 16:16:54 -05:00
NMConnection *connection,
char **specific_object)
{
policy: fix owner-ship of specific_object in can_auto_connect() NMPolicy:auto_activate_device() would wrongly not free the specific_object, although it is documented as transfer-full. The only implementation of can_auto_connect() that returned a specific-object is NMDeviceWifi:can_auto_connect(). So, there wasn't any actual bug or memory leak. Fixes: 4c028c7cefd413df3c824658fc007a96f44b0c9b
2016-09-26 15:34:07 +02:00
nm_assert (!specific_object || !*specific_object);
device: inline NMDevice's implementation of can_auto_connect() Derived classes should not modify or overwrite this essential behavior of can_auto_connect(). It doesn't belong to the virtual function.
2017-11-02 18:37:32 +01:00
return TRUE;
core: simplify nm_device_get_best_auto_connection() As with the other connection-matching methods, move the loop and the device-independent bits into NMDevice. By reusing nm_device_check_connection_compatible(), this means that most device types now no longer need any type-specific code for this. https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-03-06 16:16:54 -05:00
}
core: add nm_device_can_auto_connect() function Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-26 15:10:38 +02:00
/**
* nm_device_can_auto_connect:
* @self: an #NMDevice
* @connection: a #NMConnection
* @specific_object: (out) (transfer full): on output, the path of an
* object associated with the returned connection, to be passed to
* nm_manager_activate_connection(), or %NULL.
*
* Checks if @connection can be auto-activated on @self right now.
* This requires, at a minimum, that the connection be compatible with
* @self, and that it have the #NMSettingConnection:autoconnect property
core: autoconnect fixes for default-unmanaged devices and property notification Previously the only thing preventing default-unmanaged devices from being auto-activated was luck and the fact that they didn't have any available connections when in the UNMANAGED state. That's no longer true, so we must be more explicit about their behavior. Furthermore it makes no sense to allow default-unmanaged devices to set priv->autoconnect=TRUE since that is never supposed to happen, so enforce that both in NM itself and if the change request comes in over the D-Bus interface. Lastly, internal priv->autoconnect=TRUE changes never emitted a property change notification, meaning the NMPolicy would never schedule an autoconnect check if the device's priv->autoconnect was set to TRUE as a result of re-activating or waking from sleep.
2014-10-23 14:57:22 -05:00
* set, and that the device allow auto connections. Some devices impose
* additional requirements. (Eg, a Wi-Fi connection can only be activated
* if its SSID was seen in the last scan.)
core: add nm_device_can_auto_connect() function Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-26 15:10:38 +02:00
*
* Returns: %TRUE, if the @connection can be auto-activated.
**/
gboolean
nm_device_can_auto_connect (NMDevice *self,
NMConnection *connection,
char **specific_object)
{
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
g_return_val_if_fail (NM_IS_CONNECTION (connection), FALSE);
device: inline NMDevice's implementation of can_auto_connect() Derived classes should not modify or overwrite this essential behavior of can_auto_connect(). It doesn't belong to the virtual function.
2017-11-02 18:37:32 +01:00
g_return_val_if_fail (!specific_object || !*specific_object, FALSE);
core: add nm_device_can_auto_connect() function Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-26 15:10:38 +02:00
policy: optimize nm_device_can_auto_connect() to not check nm_device_autoconnect_allowed()
2017-11-02 18:48:02 +01:00
/* the caller must ensure that nm_device_autoconnect_allowed() returns
* TRUE as well. This is done, because nm_device_can_auto_connect()
* has only one caller, and it iterates over a list of available
* connections.
*
* Hence, we don't need to re-check nm_device_autoconnect_allowed()
* over and over again. The caller is supposed to do that. */
nm_assert (nm_device_autoconnect_allowed (self));
device: inline NMDevice's implementation of can_auto_connect() Derived classes should not modify or overwrite this essential behavior of can_auto_connect(). It doesn't belong to the virtual function.
2017-11-02 18:37:32 +01:00
if (!nm_device_check_connection_available (self, connection, NM_DEVICE_CHECK_CON_AVAILABLE_NONE, NULL))
return FALSE;
if (!NM_DEVICE_GET_CLASS (self)->can_auto_connect (self, connection, specific_object))
return FALSE;
return TRUE;
core: add nm_device_can_auto_connect() function Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-26 15:10:38 +02:00
}
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
static gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
device_has_config (NMDevice *self)
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
/* Check for IP configuration. */
if (priv->ip4_config && nm_ip4_config_get_num_addresses (priv->ip4_config))
return TRUE;
if (priv->ip6_config && nm_ip6_config_get_num_addresses (priv->ip6_config))
return TRUE;
/* The existence of a software device is good enough. */
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
if (nm_device_is_software (self) && nm_device_is_real (self))
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
return TRUE;
device: consider a device with slaves configured Do assume connections for it. https://bugzilla.redhat.com/show_bug.cgi?id=1333983
2016-09-23 20:26:07 +02:00
/* Master-slave relationship is also a configuration */
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
if ( !c_list_is_empty (&priv->slaves)
|| nm_platform_link_get_master (nm_device_get_platform (self), priv->ifindex) > 0)
core: slaves have configuration by definition The mere fact that a device is a slave means it has configuration that NetworkManager should try to read.
2013-11-07 01:11:51 -06:00
return TRUE;
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
return FALSE;
}
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
/**
* nm_device_master_update_slave_connection:
* @self: the master #NMDevice
* @slave: the slave #NMDevice
* @connection: the #NMConnection to update with the slave settings
* @GError: (out): error description
*
* Reads the slave configuration for @slave and updates @connection with those
* properties. This invokes a virtual function on the master device @self.
*
* Returns: %TRUE if the configuration was read and @connection updated,
* %FALSE on failure.
*/
gboolean
nm_device_master_update_slave_connection (NMDevice *self,
NMDevice *slave,
NMConnection *connection,
GError **error)
{
NMDeviceClass *klass;
gboolean success;
g_return_val_if_fail (self, FALSE);
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
g_return_val_if_fail (slave, FALSE);
g_return_val_if_fail (connection, FALSE);
g_return_val_if_fail (!error || !*error, FALSE);
g_return_val_if_fail (nm_connection_get_setting_connection (connection), FALSE);
core: cleanup getting iface for NMDevice for logging Since refactoring logging, these calls are not needed. Just forgot to remove them. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-02 00:48:35 +02:00
g_return_val_if_fail (nm_device_get_iface (self), FALSE);
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
klass = NM_DEVICE_GET_CLASS (self);
if (klass->master_update_slave_connection) {
success = klass->master_update_slave_connection (self, slave, connection, error);
g_return_val_if_fail (!error || (success && !*error) || *error, success);
return success;
}
g_set_error (error,
NM_DEVICE_ERROR,
libnm-core, libnm, devices: merge client and daemon NMDeviceError Merge libnm's NMDeviceError and the daemon's NMDeviceError into a single enum (in nm-errors.h). Register the domain with D-Bus, and add a test that the client side decodes it correctly. The daemon's NM_DEVICE_ERROR_CONNECTION_INVALID gets absorbed into libnm's NM_DEVICE_ERROR_INVALID_CONNECTION, and NM_DEVICE_ERROR_UNSUPPORTED_DEVICE_TYPE gets dropped, since it was only returned from one place, which is now using NM_DEVICE_ERROR_FAILED, since (a) it ought to be a "can't happen", and (b) the only caller of that function just logs error->message and then frees the error without ever looking at the code.
2014-10-15 13:47:29 -04:00
NM_DEVICE_ERROR_FAILED,
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
"master device '%s' cannot update a slave connection for slave device '%s' (master type not supported?)",
core: cleanup getting iface for NMDevice for logging Since refactoring logging, these calls are not needed. Just forgot to remove them. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-02 00:48:35 +02:00
nm_device_get_iface (self), nm_device_get_iface (slave));
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
return FALSE;
}
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
NMConnection *
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
nm_device_generate_connection (NMDevice *self,
NMDevice *master,
gboolean *out_maybe_later,
GError **error)
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDeviceClass *klass = NM_DEVICE_GET_CLASS (self);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
const char *ifname = nm_device_get_iface (self);
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
gs_unref_object NMConnection *connection = NULL;
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
NMSetting *s_con;
NMSetting *s_ip4;
NMSetting *s_ip6;
all: use stack-allocated uuid at various places No need to create a UUID on the heap in this case.
2017-02-28 16:05:39 +01:00
char uuid[37];
core: don't generate connections for some devices If the device has no IP configuration, is not a slave, and is not a master, there's no point in generating a connection for it and assuming that connection. Fixes a problem where tun devices created by vpnc would be activated with an empty assumed connection before NetworkManager could assign the VPN IP config to it, and since IPv6 link-local timed out, the tun device would be deactivated and VPN would be useless.
2013-11-08 00:35:42 -06:00
const char *ip4_method, *ip6_method;
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
GError *local = NULL;
device: use the token set in platform when generating a connection
2016-04-30 16:49:43 +02:00
const NMPlatformLink *pllink;
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
NM_SET_OUT (out_maybe_later, FALSE);
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
/* If update_connection() is not implemented, just fail. */
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
if (!klass->update_connection) {
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"device class %s does not support generating a connection",
G_OBJECT_TYPE_NAME (self));
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
return NULL;
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
}
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
/* Return NULL if device is unconfigured. */
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
if (!device_has_config (self)) {
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"device has no existing configuration");
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
return NULL;
core: generated slave connections should not have IP settings Slaves have no IP configuration and should not have any IP settings. This fixes connection comparison between generated slave connections and persistent slave connections, as persistent slave connections won't have any IP configuration.
2013-11-14 10:01:24 -06:00
}
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
libnm-core, libnm, core: make NMConnection an interface The fact that NMRemoteConnection has to be an NMConnection and therefore can't be an NMObject means that it needs to reimplement bits of NMObject functionality (and likewise NMObject needs some special magic to deal with it). Likewise, we will need a daemon-side equivalent of NMObject as part of the gdbus port, and we would want NMSettingsConnection to be able to inherit from this as well. Solve this problem by making NMConnection into an interface, and having NMRemoteConnection and NMSettingsConnection implement it. (We use some hacks to keep the GHashTable of NMSettings objects inside nm-connection.c rather than having to be implemented by the implementations.) Since NMConnection is no longer an instantiable type, this adds NMSimpleConnection to replace the various non-D-Bus-based uses of NMConnection throughout the code. nm_connection_new() becomes nm_simple_connection_new(), nm_connection_new_from_hash() becomes nm_simple_connection_new_from_hash(), and nm_connection_duplicate() becomes nm_simple_connection_new_clone().
2014-08-13 14:34:29 -04:00
connection = nm_simple_connection_new ();
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
s_con = nm_setting_connection_new ();
g_object_set (s_con,
all: use stack-allocated uuid at various places No need to create a UUID on the heap in this case.
2017-02-28 16:05:39 +01:00
NM_SETTING_CONNECTION_UUID, nm_utils_uuid_generate_buf (uuid),
core: no need to clone ifname in nm_device_generate_connection() Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-26 02:30:22 +02:00
NM_SETTING_CONNECTION_ID, ifname,
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
NM_SETTING_CONNECTION_AUTOCONNECT, FALSE,
core: improve ifname matching of existing x generated connections (rh #1077743) DEVICE="ens3" ONBOOT=yes NETBOOT=yes UUID="23466771-f5fa-4ca9-856f-eaf4a8e20c3f" BOOTPROTO=none IPADDR="10.0.0.2" PREFIX="24" GATEWAY="10.0.0.1" HWADDR="52:54:00:12:34:56" TYPE=Ethernet NAME="ens3" This ifcfg file results in connection.interface-name=ens3. However, device-generated connection didn't set interface-name property. Fix that by setting interface-name property when generating a connection. Also allow matching connections if interface-name is not set in a connection. https://bugzilla.redhat.com/show_bug.cgi?id=1077743
2014-03-18 14:21:59 +01:00
NM_SETTING_CONNECTION_INTERFACE_NAME, ifname,
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
NM_SETTING_CONNECTION_TIMESTAMP, (guint64) time (NULL),
NULL);
if (klass->connection_type)
g_object_set (s_con, NM_SETTING_CONNECTION_TYPE, klass->connection_type, NULL);
nm_connection_add_setting (connection, s_con);
core: slaves should have empty captured IP configuration
2013-11-06 14:13:59 -06:00
core: support slave devices in nm_platform_generate_connection() Ask each device class to update the slave configuration for their type of slave.
2013-08-22 20:41:01 +02:00
/* If the device is a slave, update various slave settings */
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
if (master) {
if (!nm_device_master_update_slave_connection (master,
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
self,
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
connection,
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
&local)) {
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"master device '%s' failed to update slave connection: %s",
nm_device_get_iface (master), local->message);
g_error_free (local);
core: refactor update_slave_connection() as virtual function of master device Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-18 20:17:57 +02:00
return NULL;
core: support slave devices in nm_platform_generate_connection() Ask each device class to update the slave configuration for their type of slave.
2013-08-22 20:41:01 +02:00
}
core: generated slave connections should not have IP settings Slaves have no IP configuration and should not have any IP settings. This fixes connection comparison between generated slave connections and persistent slave connections, as persistent slave connections won't have any IP configuration.
2013-11-14 10:01:24 -06:00
} else {
/* Only regular and master devices get IP configuration; slaves do not */
core: tweak NMSettingIP[46]Config generation NMIP4Config and NMIP6Config had methods to update an existing NMSetting. However, the functions would really only work correctly if the passed-in setting was empty. Change them from "update_setting" to "create_setting", and have them create the NMSetting themselves, and update NMDevice for that. (If we need update_setting later, we can add it, after figuring out exactly how it's actually supposed to work.)
2014-05-19 10:24:15 -04:00
s_ip4 = nm_ip4_config_create_setting (priv->ip4_config);
core: generated slave connections should not have IP settings Slaves have no IP configuration and should not have any IP settings. This fixes connection comparison between generated slave connections and persistent slave connections, as persistent slave connections won't have any IP configuration.
2013-11-14 10:01:24 -06:00
nm_connection_add_setting (connection, s_ip4);
core: tweak NMSettingIP[46]Config generation NMIP4Config and NMIP6Config had methods to update an existing NMSetting. However, the functions would really only work correctly if the passed-in setting was empty. Change them from "update_setting" to "create_setting", and have them create the NMSetting themselves, and update NMDevice for that. (If we need update_setting later, we can add it, after figuring out exactly how it's actually supposed to work.)
2014-05-19 10:24:15 -04:00
s_ip6 = nm_ip6_config_create_setting (priv->ip6_config);
core: generated slave connections should not have IP settings Slaves have no IP configuration and should not have any IP settings. This fixes connection comparison between generated slave connections and persistent slave connections, as persistent slave connections won't have any IP configuration.
2013-11-14 10:01:24 -06:00
nm_connection_add_setting (connection, s_ip6);
device: use the token set in platform when generating a connection
2016-04-30 16:49:43 +02:00
device: add proxy setting to generated connections Add a proxy setting to generated connections because after commit 6f94b1650764 ("libnm: fix nm_connection_diff() for settings without properties") the matching between a connection having the setting and another connection without it fails. Before the commit, since no proxy property is marked as inferrable, such comparison succeeded.
2017-10-27 18:24:19 +02:00
nm_connection_add_setting (connection, nm_setting_proxy_new ());
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
pllink = nm_platform_link_get (nm_device_get_platform (self), priv->ifindex);
device: use the token set in platform when generating a connection
2016-04-30 16:49:43 +02:00
if (pllink && pllink->inet6_token.id) {
g_object_set (s_ip6,
NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE, NM_IN6_ADDR_GEN_MODE_EUI64,
NM_SETTING_IP6_CONFIG_TOKEN, nm_utils_inet6_interface_identifier_to_token (pllink->inet6_token, NULL),
NULL);
}
core: support slave devices in nm_platform_generate_connection() Ask each device class to update the slave configuration for their type of slave.
2013-08-22 20:41:01 +02:00
}
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
klass->update_connection (self, connection);
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
if (!nm_connection_verify (connection, &local)) {
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"generated connection does not verify: %s",
local->message);
g_error_free (local);
devices: if a generated connection doesn't verify, log why
2014-03-26 12:39:13 -04:00
return NULL;
}
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
core: don't generate connections for some devices If the device has no IP configuration, is not a slave, and is not a master, there's no point in generating a connection for it and assuming that connection. Fixes a problem where tun devices created by vpnc would be activated with an empty assumed connection before NetworkManager could assign the VPN IP config to it, and since IPv6 link-local timed out, the tun device would be deactivated and VPN would be useless.
2013-11-08 00:35:42 -06:00
/* Ignore the connection if it has no IP configuration,
* no slave configuration, and is not a master interface.
*/
core: generated slave connections should not have IP settings Slaves have no IP configuration and should not have any IP settings. This fixes connection comparison between generated slave connections and persistent slave connections, as persistent slave connections won't have any IP configuration.
2013-11-14 10:01:24 -06:00
ip4_method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP4_CONFIG);
ip6_method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG);
if ( g_strcmp0 (ip4_method, NM_SETTING_IP4_CONFIG_METHOD_DISABLED) == 0
&& g_strcmp0 (ip6_method, NM_SETTING_IP6_CONFIG_METHOD_IGNORE) == 0
device: assume connections for device with slaves If a bridge/team/bond has slaves, assume it's connected. Recheck as devices appear. https://bugzilla.redhat.com/show_bug.cgi?id=1141266
2014-12-05 17:49:11 +01:00
&& !nm_setting_connection_get_master (NM_SETTING_CONNECTION (s_con))
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
&& c_list_is_empty (&priv->slaves)) {
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
NM_SET_OUT (out_maybe_later, TRUE);
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
g_set_error_literal (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"ignoring generated connection (no IP and not in master-slave relationship)");
return NULL;
device: don't assume by default IPv6LL-only connections Add the new configuration option 'assume-ipv6ll-only' which specifies the devices for which NM will try to assume an existing IPv6LL-only configuration. The new default behavior is to ignore such configurations since IPv6LL addresses are automatically assigned by the kernel when the device is brought up and thus the presence of an IPv6LL address doesn't mean that the device was configured by the administrator. The previous behavior was to always assume IPv6LL-only configurations but this often had the unwanted effect of preventing other on-disk configurations to be activated. To preserve the old behavior the option must be set to '*'. https://bugzilla.redhat.com/show_bug.cgi?id=1138426
2015-05-20 11:36:37 +02:00
}
/* Ignore any IPv6LL-only, not master connections without slaves,
* unless they are in the assume-ipv6ll-only list.
*/
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
if ( g_strcmp0 (ip4_method, NM_SETTING_IP4_CONFIG_METHOD_DISABLED) == 0
device: don't assume by default IPv6LL-only connections Add the new configuration option 'assume-ipv6ll-only' which specifies the devices for which NM will try to assume an existing IPv6LL-only configuration. The new default behavior is to ignore such configurations since IPv6LL addresses are automatically assigned by the kernel when the device is brought up and thus the presence of an IPv6LL address doesn't mean that the device was configured by the administrator. The previous behavior was to always assume IPv6LL-only configurations but this often had the unwanted effect of preventing other on-disk configurations to be activated. To preserve the old behavior the option must be set to '*'. https://bugzilla.redhat.com/show_bug.cgi?id=1138426
2015-05-20 11:36:37 +02:00
&& g_strcmp0 (ip6_method, NM_SETTING_IP6_CONFIG_METHOD_LINK_LOCAL) == 0
&& !nm_setting_connection_get_master (NM_SETTING_CONNECTION (s_con))
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
&& c_list_is_empty (&priv->slaves)
config: add macros NM_CONFIG_GET_DATA and NM_CONFIG_GET_DATA_ORIG
2015-06-09 08:47:41 +02:00
&& !nm_config_data_get_assume_ipv6ll_only (NM_CONFIG_GET_DATA, self)) {
device: don't assume by default IPv6LL-only connections Add the new configuration option 'assume-ipv6ll-only' which specifies the devices for which NM will try to assume an existing IPv6LL-only configuration. The new default behavior is to ignore such configurations since IPv6LL addresses are automatically assigned by the kernel when the device is brought up and thus the presence of an IPv6LL address doesn't mean that the device was configured by the administrator. The previous behavior was to always assume IPv6LL-only configurations but this often had the unwanted effect of preventing other on-disk configurations to be activated. To preserve the old behavior the option must be set to '*'. https://bugzilla.redhat.com/show_bug.cgi?id=1138426
2015-05-20 11:36:37 +02:00
_LOGD (LOGD_DEVICE, "ignoring generated connection (IPv6LL-only and not in master-slave relationship)");
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
NM_SET_OUT (out_maybe_later, TRUE);
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
g_set_error_literal (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_FAILED,
"ignoring generated connection (IPv6LL-only and not in master-slave relationship)");
return NULL;
core: don't generate connections for some devices If the device has no IP configuration, is not a slave, and is not a master, there's no point in generating a connection for it and assuming that connection. Fixes a problem where tun devices created by vpnc would be activated with an empty assumed connection before NetworkManager could assign the VPN IP config to it, and since IPv6 link-local timed out, the tun device would be deactivated and VPN would be useless.
2013-11-08 00:35:42 -06:00
}
device: suppress logging and return error reason from nm_device_generate_connection() Don't log in a function that basically just inspects state, without mutating it. Instead, pass the reason why a connection could not be generated to the caller so that we have one sensible log message.
2017-06-07 17:04:33 +02:00
return g_steal_pointer (&connection);
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
}
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
gboolean
nm_device_complete_connection (NMDevice *self,
NMConnection *connection,
const char *specific_object,
const GSList *existing_connections,
GError **error)
{
gboolean success = FALSE;
g_return_val_if_fail (self != NULL, FALSE);
g_return_val_if_fail (connection != NULL, FALSE);
if (!NM_DEVICE_GET_CLASS (self)->complete_connection) {
libnm-core, libnm, devices: merge client and daemon NMDeviceError Merge libnm's NMDeviceError and the daemon's NMDeviceError into a single enum (in nm-errors.h). Register the domain with D-Bus, and add a test that the client side decodes it correctly. The daemon's NM_DEVICE_ERROR_CONNECTION_INVALID gets absorbed into libnm's NM_DEVICE_ERROR_INVALID_CONNECTION, and NM_DEVICE_ERROR_UNSUPPORTED_DEVICE_TYPE gets dropped, since it was only returned from one place, which is now using NM_DEVICE_ERROR_FAILED, since (a) it ought to be a "can't happen", and (b) the only caller of that function just logs error->message and then frees the error without ever looking at the code.
2014-10-15 13:47:29 -04:00
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_INVALID_CONNECTION,
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
"Device class %s had no complete_connection method",
G_OBJECT_TYPE_NAME (self));
return FALSE;
}
success = NM_DEVICE_GET_CLASS (self)->complete_connection (self,
connection,
specific_object,
existing_connections,
error);
if (success)
success = nm_connection_verify (connection, error);
return success;
}
device: deduplicate match_parent()
2017-09-27 09:40:45 +02:00
gboolean
nm_device_match_parent (NMDevice *self, const char *parent)
{
NMDevice *parent_device;
g_return_val_if_fail (parent, FALSE);
parent_device = nm_device_parent_get_device (self);
if (!parent_device)
return FALSE;
if (nm_utils_is_uuid (parent)) {
NMConnection *connection;
device: match all UUIDs when no connection is active nm_device_match_parent() is called to check whether a device is compatible with a given parent (UUID or interface). Accept any UUID If there is no connection active on the device. Without this, when there is a VLAN/MACVLAN connection with a parent UUID the manager would create the device in system_create_virtual_device(), realize it and then at the next call of system_create_virtual_device() it would notice that the connection is not compatible with the device because of the parent UUID; therefore the manager would try to create again the same device, failing. https://mail.gnome.org/archives/networkmanager-list/2017-September/msg00034.html
2017-09-27 10:23:31 +02:00
/* If the parent is a UUID, the connection matches when there is
* no connection active on the device or when a connection with
* that UUID is active.
device: deduplicate match_parent()
2017-09-27 09:40:45 +02:00
*/
connection = nm_device_get_applied_connection (self);
if (!connection)
device: match all UUIDs when no connection is active nm_device_match_parent() is called to check whether a device is compatible with a given parent (UUID or interface). Accept any UUID If there is no connection active on the device. Without this, when there is a VLAN/MACVLAN connection with a parent UUID the manager would create the device in system_create_virtual_device(), realize it and then at the next call of system_create_virtual_device() it would notice that the connection is not compatible with the device because of the parent UUID; therefore the manager would try to create again the same device, failing. https://mail.gnome.org/archives/networkmanager-list/2017-September/msg00034.html
2017-09-27 10:23:31 +02:00
return TRUE;
device: deduplicate match_parent()
2017-09-27 09:40:45 +02:00
if (!nm_streq0 (parent, nm_connection_get_uuid (connection)))
return FALSE;
} else {
/* Interface name */
if (!nm_streq0 (parent, nm_device_get_ip_iface (parent_device)))
return FALSE;
}
return TRUE;
}
device: deduplicate match_hwaddr()
2017-09-27 09:47:22 +02:00
gboolean
nm_device_match_hwaddr (NMDevice *device,
NMConnection *connection,
gboolean fail_if_no_hwaddr)
{
NMSettingWired *s_wired;
NMDevice *parent_device;
const char *setting_mac;
const char *parent_mac;
s_wired = nm_connection_get_setting_wired (connection);
if (!s_wired)
return !fail_if_no_hwaddr;
setting_mac = nm_setting_wired_get_mac_address (s_wired);
if (!setting_mac)
return !fail_if_no_hwaddr;
parent_device = nm_device_parent_get_device (device);
if (!parent_device)
return !fail_if_no_hwaddr;
parent_mac = nm_device_get_permanent_hw_address (parent_device);
return parent_mac && nm_utils_hwaddr_matches (setting_mac, -1, parent_mac, -1);
}
core: make nm_device_check_connection_compatible() check interface-name If an NMConnection specifies an interface-name, it is only compatible with a device with the same iface. https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-03-07 07:44:36 -05:00
static gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
check_connection_compatible (NMDevice *self, NMConnection *connection)
core: make nm_device_check_connection_compatible() check interface-name If an NMConnection specifies an interface-name, it is only compatible with a device with the same iface. https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-03-07 07:44:36 -05:00
{
device: move the interface name check from manager We not only want to check the device name when creating a virtual device, but also when determining if the connection can actually be activated there. Otherwise the device names will mix up if there's more connections that use virtual devices of the same type.
2016-02-16 15:07:57 +01:00
const char *device_iface = nm_device_get_iface (self);
gs_free char *conn_iface = nm_manager_get_connection_iface (nm_manager_get (),
connection,
NULL, NULL);
/* We always need a interface name for virtual devices, but for
* physical ones a connection without interface name is fine for
* any device. */
if (!conn_iface)
return !nm_connection_is_virtual (connection);
if (strcmp (conn_iface, device_iface) != 0)
core: make nm_device_check_connection_compatible() check interface-name If an NMConnection specifies an interface-name, it is only compatible with a device with the same iface. https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-03-07 07:44:36 -05:00
return FALSE;
return TRUE;
}
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
/**
* nm_device_check_connection_compatible:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: an #NMDevice
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
* @connection: an #NMConnection
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* Checks if @connection could potentially be activated on @self.
* This means only that @self has the proper capabilities, and that
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
* @connection is not locked to some other device. It does not
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* necessarily mean that @connection could be activated on @self
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
* right now. (Eg, it might refer to a Wi-Fi network that is not
* currently available.)
*
* Returns: #TRUE if @connection could potentially be activated on
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self.
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
*/
core: move nm_device_interface_check_connection_compatible() to nm-device.c
2011-11-17 23:04:47 -06:00
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_check_connection_compatible (NMDevice *self, NMConnection *connection)
core: move nm_device_interface_check_connection_compatible() to nm-device.c
2011-11-17 23:04:47 -06:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
core: move nm_device_interface_check_connection_compatible() to nm-device.c
2011-11-17 23:04:47 -06:00
g_return_val_if_fail (NM_IS_CONNECTION (connection), FALSE);
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
return NM_DEVICE_GET_CLASS (self)->check_connection_compatible (self, connection);
core: move nm_device_interface_check_connection_compatible() to nm-device.c
2011-11-17 23:04:47 -06:00
}
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d core: allow ActiveConnections to be created without a device But it's not easy to do a separate revert of that code due to interdependencies with nm-manager.c. Creating devices when they are defined by a connection also makes makes it possible to require the NMDevice to be present when activating it, which means we can remove a bunch of code from NMManager that had to handle software devices not existing yet at the time of the activation request. But it also means we must be more careful when finding master interfaces during slave activation, since we cannot simply match by interface name alone. Instead we must find the master which matches both the interface name and can control slaves of the type which is being activated.
2014-10-15 21:17:45 -05:00
gboolean
nm_device_check_slave_connection_compatible (NMDevice *self, NMConnection *slave)
{
NMDevicePrivate *priv;
NMSettingConnection *s_con;
const char *connection_type, *slave_type;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
g_return_val_if_fail (NM_IS_CONNECTION (slave), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
device: transform NM_DEVICE_IS_MASTER gobject property to field in NMDeviceClass We don't need this flexibility of having a full fledged GObject property for is-master. The property value only depends on the device's class.
2017-06-01 23:08:30 +02:00
if (!nm_device_is_master (self))
core: allow multiple devices with the same interface name But, of course, only one realized device can have the same interface name at a time. This commit effectively reverts most of: 1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d core: allow ActiveConnections to be created without a device But it's not easy to do a separate revert of that code due to interdependencies with nm-manager.c. Creating devices when they are defined by a connection also makes makes it possible to require the NMDevice to be present when activating it, which means we can remove a bunch of code from NMManager that had to handle software devices not existing yet at the time of the activation request. But it also means we must be more careful when finding master interfaces during slave activation, since we cannot simply match by interface name alone. Instead we must find the master which matches both the interface name and can control slaves of the type which is being activated.
2014-10-15 21:17:45 -05:00
return FALSE;
/* All masters should have connection type set */
connection_type = NM_DEVICE_GET_CLASS (self)->connection_type;
g_return_val_if_fail (connection_type, FALSE);
s_con = nm_connection_get_setting_connection (slave);
g_assert (s_con);
slave_type = nm_setting_connection_get_slave_type (s_con);
if (!slave_type)
return FALSE;
return strcmp (connection_type, slave_type) == 0;
}
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
/**
* nm_device_can_assume_connections:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: #NMDevice instance
core: match connections to connections instead of devices 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>
2013-06-27 14:39:13 +02:00
*
* This is a convenience function to determine whether connection assumption
* is available for this device.
*
core: don't do anything interesting in NMDevice dispose() The NMDevice dispose() function contained some badly-duplicated logic about when to deactivate a device on its last ref. This logic should only run when the device is removed by the manager, since the manager controls the device's life-cycle, and the manager knows best when to clean up the device. But since it was tied to the device's refcount, it could have run later than the manager wanted, or not at all. It gets better. Dispose duplicated logic that was already done in nm_device_cleanup(), and then *called* nm_device_cleanup() if the device was still activated and managed. But the manager already unmanages the device when removing it, which triggers a call to nm_device_cleanup(), takes the device down, and resets the IPv6 sysctl properties, which dispose() duplicated too. So by the time dispose() runs, the device should already be unmanaged if the manager wants to deconfigure it, and most of the dispose() code should be a no-op. Clean all that up and remove duplicated functions. Now, the flow should be like this: 1) manager decides to remove the device and calls remove_device() 2) if the device should be deconfigured, the manager unmanages the device 3) the NMDevice state change handler tears down the active connection via nm_device_cleanup() and resets IPv6 sysctl properties 4) when the device's last reference is finally released, only internal data members are freed in dispose() because the device should already have been cleaned up by the manager and be unmanaged 5) if the device should be left running because it has an assumable connection, then the device is not unmanaged, and no cleanup happens in the state change handler or in dispose()
2014-05-23 15:41:46 -05:00
* Returns: %TRUE if the device is capable of assuming connections, %FALSE if not
*/
static gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_can_assume_connections (NMDevice *self)
core: don't do anything interesting in NMDevice dispose() The NMDevice dispose() function contained some badly-duplicated logic about when to deactivate a device on its last ref. This logic should only run when the device is removed by the manager, since the manager controls the device's life-cycle, and the manager knows best when to clean up the device. But since it was tied to the device's refcount, it could have run later than the manager wanted, or not at all. It gets better. Dispose duplicated logic that was already done in nm_device_cleanup(), and then *called* nm_device_cleanup() if the device was still activated and managed. But the manager already unmanages the device when removing it, which triggers a call to nm_device_cleanup(), takes the device down, and resets the IPv6 sysctl properties, which dispose() duplicated too. So by the time dispose() runs, the device should already be unmanaged if the manager wants to deconfigure it, and most of the dispose() code should be a no-op. Clean all that up and remove duplicated functions. Now, the flow should be like this: 1) manager decides to remove the device and calls remove_device() 2) if the device should be deconfigured, the manager unmanages the device 3) the NMDevice state change handler tears down the active connection via nm_device_cleanup() and resets IPv6 sysctl properties 4) when the device's last reference is finally released, only internal data members are freed in dispose() because the device should already have been cleaned up by the manager and be unmanaged 5) if the device should be left running because it has an assumable connection, then the device is not unmanaged, and no cleanup happens in the state change handler or in dispose()
2014-05-23 15:41:46 -05:00
{
core: refactor unmanaging devices on shutdown and unmanage Wi-Fi devices Add new virtual function nm_device_unmanage_on_quit() to determine whether to unmanage the device on shutdown. This allows Wi-Fi devices to always be unmanaged. We want that to reset the initial MAC address.
2016-06-21 11:04:38 +02:00
return !!NM_DEVICE_GET_CLASS (self)->update_connection;
core: don't do anything interesting in NMDevice dispose() The NMDevice dispose() function contained some badly-duplicated logic about when to deactivate a device on its last ref. This logic should only run when the device is removed by the manager, since the manager controls the device's life-cycle, and the manager knows best when to clean up the device. But since it was tied to the device's refcount, it could have run later than the manager wanted, or not at all. It gets better. Dispose duplicated logic that was already done in nm_device_cleanup(), and then *called* nm_device_cleanup() if the device was still activated and managed. But the manager already unmanages the device when removing it, which triggers a call to nm_device_cleanup(), takes the device down, and resets the IPv6 sysctl properties, which dispose() duplicated too. So by the time dispose() runs, the device should already be unmanaged if the manager wants to deconfigure it, and most of the dispose() code should be a no-op. Clean all that up and remove duplicated functions. Now, the flow should be like this: 1) manager decides to remove the device and calls remove_device() 2) if the device should be deconfigured, the manager unmanages the device 3) the NMDevice state change handler tears down the active connection via nm_device_cleanup() and resets IPv6 sysctl properties 4) when the device's last reference is finally released, only internal data members are freed in dispose() because the device should already have been cleaned up by the manager and be unmanaged 5) if the device should be left running because it has an assumable connection, then the device is not unmanaged, and no cleanup happens in the state change handler or in dispose()
2014-05-23 15:41:46 -05:00
}
core: refactor unmanaging devices on shutdown and unmanage Wi-Fi devices Add new virtual function nm_device_unmanage_on_quit() to determine whether to unmanage the device on shutdown. This allows Wi-Fi devices to always be unmanaged. We want that to reset the initial MAC address.
2016-06-21 11:04:38 +02:00
static gboolean
core: don't unmanage devices on shutdown ... except Wi-Fi and devices that cannot assume connections at all. https://bugzilla.redhat.com/show_bug.cgi?id=1371126 https://bugzilla.redhat.com/show_bug.cgi?id=1378418
2016-10-11 14:42:35 +02:00
unmanaged_on_quit (NMDevice *self)
core: move nm_device_interface_can_assume_connections() to nm-device.c
2011-11-17 23:10:11 -06:00
{
core: don't do anything interesting in NMDevice dispose() The NMDevice dispose() function contained some badly-duplicated logic about when to deactivate a device on its last ref. This logic should only run when the device is removed by the manager, since the manager controls the device's life-cycle, and the manager knows best when to clean up the device. But since it was tied to the device's refcount, it could have run later than the manager wanted, or not at all. It gets better. Dispose duplicated logic that was already done in nm_device_cleanup(), and then *called* nm_device_cleanup() if the device was still activated and managed. But the manager already unmanages the device when removing it, which triggers a call to nm_device_cleanup(), takes the device down, and resets the IPv6 sysctl properties, which dispose() duplicated too. So by the time dispose() runs, the device should already be unmanaged if the manager wants to deconfigure it, and most of the dispose() code should be a no-op. Clean all that up and remove duplicated functions. Now, the flow should be like this: 1) manager decides to remove the device and calls remove_device() 2) if the device should be deconfigured, the manager unmanages the device 3) the NMDevice state change handler tears down the active connection via nm_device_cleanup() and resets IPv6 sysctl properties 4) when the device's last reference is finally released, only internal data members are freed in dispose() because the device should already have been cleaned up by the manager and be unmanaged 5) if the device should be left running because it has an assumable connection, then the device is not unmanaged, and no cleanup happens in the state change handler or in dispose()
2014-05-23 15:41:46 -05:00
NMConnection *connection;
core: don't unmanage devices on shutdown ... except Wi-Fi and devices that cannot assume connections at all. https://bugzilla.redhat.com/show_bug.cgi?id=1371126 https://bugzilla.redhat.com/show_bug.cgi?id=1378418
2016-10-11 14:42:35 +02:00
/* NMDeviceWifi overwrites this function to always unmanage wifi devices.
*
* For all other types, if the device type can assume connections, we leave
* it up on quit.
*
* Originally, we would only keep devices up that can be assumed afterwards.
* However, that meant we unmanged layer-2 only devices. So, this was step
* by step refined to unmanage less (commit 25aaaab3, rh#1311988, rh#1333983).
* But there are more scenarios where we also want to keep the device up
* (rh#1378418, rh#1371126). */
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
if (!nm_device_can_assume_connections (self))
core: don't unmanage devices on shutdown ... except Wi-Fi and devices that cannot assume connections at all. https://bugzilla.redhat.com/show_bug.cgi?id=1371126 https://bugzilla.redhat.com/show_bug.cgi?id=1378418
2016-10-11 14:42:35 +02:00
return TRUE;
core: don't do anything interesting in NMDevice dispose() The NMDevice dispose() function contained some badly-duplicated logic about when to deactivate a device on its last ref. This logic should only run when the device is removed by the manager, since the manager controls the device's life-cycle, and the manager knows best when to clean up the device. But since it was tied to the device's refcount, it could have run later than the manager wanted, or not at all. It gets better. Dispose duplicated logic that was already done in nm_device_cleanup(), and then *called* nm_device_cleanup() if the device was still activated and managed. But the manager already unmanages the device when removing it, which triggers a call to nm_device_cleanup(), takes the device down, and resets the IPv6 sysctl properties, which dispose() duplicated too. So by the time dispose() runs, the device should already be unmanaged if the manager wants to deconfigure it, and most of the dispose() code should be a no-op. Clean all that up and remove duplicated functions. Now, the flow should be like this: 1) manager decides to remove the device and calls remove_device() 2) if the device should be deconfigured, the manager unmanages the device 3) the NMDevice state change handler tears down the active connection via nm_device_cleanup() and resets IPv6 sysctl properties 4) when the device's last reference is finally released, only internal data members are freed in dispose() because the device should already have been cleaned up by the manager and be unmanaged 5) if the device should be left running because it has an assumable connection, then the device is not unmanaged, and no cleanup happens in the state change handler or in dispose()
2014-05-23 15:41:46 -05:00
core: don't unmanage devices on shutdown ... except Wi-Fi and devices that cannot assume connections at all. https://bugzilla.redhat.com/show_bug.cgi?id=1371126 https://bugzilla.redhat.com/show_bug.cgi?id=1378418
2016-10-11 14:42:35 +02:00
/* the only exception are IPv4 shared connections. We unmanage them on quit. */
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
core: don't unmanage devices on shutdown ... except Wi-Fi and devices that cannot assume connections at all. https://bugzilla.redhat.com/show_bug.cgi?id=1371126 https://bugzilla.redhat.com/show_bug.cgi?id=1378418
2016-10-11 14:42:35 +02:00
if (connection) {
if (NM_IN_STRSET (nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP4_CONFIG),
NM_SETTING_IP4_CONFIG_METHOD_SHARED)) {
/* shared connections are to be unmangaed. */
return TRUE;
}
core: refactor unmanaging devices on shutdown and unmanage Wi-Fi devices Add new virtual function nm_device_unmanage_on_quit() to determine whether to unmanage the device on shutdown. This allows Wi-Fi devices to always be unmanaged. We want that to reset the initial MAC address.
2016-06-21 11:04:38 +02:00
}
core: don't unmanage devices on shutdown ... except Wi-Fi and devices that cannot assume connections at all. https://bugzilla.redhat.com/show_bug.cgi?id=1371126 https://bugzilla.redhat.com/show_bug.cgi?id=1378418
2016-10-11 14:42:35 +02:00
return FALSE;
core: refactor unmanaging devices on shutdown and unmanage Wi-Fi devices Add new virtual function nm_device_unmanage_on_quit() to determine whether to unmanage the device on shutdown. This allows Wi-Fi devices to always be unmanaged. We want that to reset the initial MAC address.
2016-06-21 11:04:38 +02:00
}
gboolean
nm_device_unmanage_on_quit (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
return NM_DEVICE_GET_CLASS (self)->unmanaged_on_quit (self);
}
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
static gboolean
device: don't pass void* pointer to NM_DEVICE_GET_PRIVATE()
2015-12-07 16:34:48 +01:00
nm_device_emit_recheck_assume (gpointer user_data)
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
{
device: don't pass void* pointer to NM_DEVICE_GET_PRIVATE()
2015-12-07 16:34:48 +01:00
NMDevice *self = user_data;
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), G_SOURCE_REMOVE);
priv = NM_DEVICE_GET_PRIVATE (self);
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
priv->recheck_assume_id = 0;
device: remove logging for emitting RECHECK_ASSUME signal The device's RECHECK_ASSUME signal has only NMManager as subscriber and it immediately calls recheck_assume_connection(). With the previous commit, recheck_assume_connection() always logs a debug message, so we don't need this duplicate message anymore.
2017-06-07 13:44:07 +02:00
if (!nm_device_get_act_request (self))
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
g_signal_emit (self, signals[RECHECK_ASSUME], 0);
device: remove logging for emitting RECHECK_ASSUME signal The device's RECHECK_ASSUME signal has only NMManager as subscriber and it immediately calls recheck_assume_connection(). With the previous commit, recheck_assume_connection() always logs a debug message, so we don't need this duplicate message anymore.
2017-06-07 13:44:07 +02:00
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
return G_SOURCE_REMOVE;
}
void
nm_device_queue_recheck_assume (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
if ( !priv->recheck_assume_id
&& nm_device_can_assume_connections (self))
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
priv->recheck_assume_id = g_idle_add (nm_device_emit_recheck_assume, self);
}
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
static gboolean
recheck_available (gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
gboolean now_available;
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
NMDeviceState state = nm_device_get_state (self);
NMDeviceState new_state = NM_DEVICE_STATE_UNKNOWN;
priv->recheck_available.call_id = 0;
core: minor cleanups Some minor changes that make the code more similar to what will be done later for the related bug bgo#746440.
2017-03-01 17:26:45 +01:00
now_available = nm_device_is_available (self, NM_DEVICE_CHECK_DEV_AVAILABLE_NONE);
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
if (state == NM_DEVICE_STATE_UNAVAILABLE && now_available) {
new_state = NM_DEVICE_STATE_DISCONNECTED;
nm_device_queue_state (self, new_state, priv->recheck_available.available_reason);
} else if (state >= NM_DEVICE_STATE_DISCONNECTED && !now_available) {
new_state = NM_DEVICE_STATE_UNAVAILABLE;
nm_device_queue_state (self, new_state, priv->recheck_available.unavailable_reason);
}
core: only run availability recheck transition if required Device subclasses can call nm_device_recheck_available() at any time, and the function would change the device's state to UNKNOWN in cases where the device was available already. For WWAN devices, availability is rechecked every time the modem state changes, resulting in: NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'disabled' --> 'enabling' (reason: user-requested) NetworkManager[28919]: <debug> [1445538582.116727] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'enabling' --> 'searching' (reason: user-requested) NetworkManager[28919]: <debug> [1445538582.776317] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown
2015-10-22 13:42:42 -05:00
if (new_state > NM_DEVICE_STATE_UNKNOWN) {
device: improve logging messages Add a "device" prefix to the messages.
2016-03-03 09:20:00 +01:00
_LOGD (LOGD_DEVICE, "is %savailable, %s %s",
device: move tracking of parent device from NMDeviceMacvlan to NMDevice
2017-01-02 09:27:20 +01:00
now_available ? "" : "not ",
new_state == NM_DEVICE_STATE_UNAVAILABLE ? "no change required for" : "will transition to",
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (new_state == NM_DEVICE_STATE_UNAVAILABLE ? state : new_state));
core: only run availability recheck transition if required Device subclasses can call nm_device_recheck_available() at any time, and the function would change the device's state to UNKNOWN in cases where the device was available already. For WWAN devices, availability is rechecked every time the modem state changes, resulting in: NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'disabled' --> 'enabling' (reason: user-requested) NetworkManager[28919]: <debug> [1445538582.116727] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'enabling' --> 'searching' (reason: user-requested) NetworkManager[28919]: <debug> [1445538582.776317] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown
2015-10-22 13:42:42 -05:00
priv->recheck_available.available_reason = NM_DEVICE_STATE_REASON_NONE;
priv->recheck_available.unavailable_reason = NM_DEVICE_STATE_REASON_NONE;
}
device: add pending-action "recheck-available" Startup-complete means that all devices have settled in a state and no further activation is pending. When we have a recheck-available scheduled, we clearly should not yet declare startup-complete. Add a new pending-action "recheck-available" to avoid: <info> [1485520408.3920] device (wlp2s0): supplicant interface state: starting -> ready <debug> [1485520408.3920] device[0x563abbcca400] (wlp2s0): remove_pending_action (0): 'waiting for supplicant' <info> [1485520408.3920] manager: startup complete <debug> [1485520408.3924] device[0x563abbcca400] (wlp2s0): add_pending_action (1): 'queued state change to disconnected'
2017-01-27 13:52:26 +01:00
if (priv->recheck_available.call_id == 0)
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_remove_pending_action (self, NM_PENDING_ACTION_RECHECK_AVAILABLE, TRUE);
device: add pending-action "recheck-available" Startup-complete means that all devices have settled in a state and no further activation is pending. When we have a recheck-available scheduled, we clearly should not yet declare startup-complete. Add a new pending-action "recheck-available" to avoid: <info> [1485520408.3920] device (wlp2s0): supplicant interface state: starting -> ready <debug> [1485520408.3920] device[0x563abbcca400] (wlp2s0): remove_pending_action (0): 'waiting for supplicant' <info> [1485520408.3920] manager: startup complete <debug> [1485520408.3924] device[0x563abbcca400] (wlp2s0): add_pending_action (1): 'queued state change to disconnected'
2017-01-27 13:52:26 +01:00
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
return G_SOURCE_REMOVE;
}
void
nm_device_queue_recheck_available (NMDevice *self,
NMDeviceStateReason available_reason,
NMDeviceStateReason unavailable_reason)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
priv->recheck_available.available_reason = available_reason;
priv->recheck_available.unavailable_reason = unavailable_reason;
device: add pending-action "recheck-available" Startup-complete means that all devices have settled in a state and no further activation is pending. When we have a recheck-available scheduled, we clearly should not yet declare startup-complete. Add a new pending-action "recheck-available" to avoid: <info> [1485520408.3920] device (wlp2s0): supplicant interface state: starting -> ready <debug> [1485520408.3920] device[0x563abbcca400] (wlp2s0): remove_pending_action (0): 'waiting for supplicant' <info> [1485520408.3920] manager: startup complete <debug> [1485520408.3924] device[0x563abbcca400] (wlp2s0): add_pending_action (1): 'queued state change to disconnected'
2017-01-27 13:52:26 +01:00
if (!priv->recheck_available.call_id) {
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
priv->recheck_available.call_id = g_idle_add (recheck_available, self);
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_add_pending_action (self, NM_PENDING_ACTION_RECHECK_AVAILABLE,
device: add pending-action "recheck-available" Startup-complete means that all devices have settled in a state and no further activation is pending. When we have a recheck-available scheduled, we clearly should not yet declare startup-complete. Add a new pending-action "recheck-available" to avoid: <info> [1485520408.3920] device (wlp2s0): supplicant interface state: starting -> ready <debug> [1485520408.3920] device[0x563abbcca400] (wlp2s0): remove_pending_action (0): 'waiting for supplicant' <info> [1485520408.3920] manager: startup complete <debug> [1485520408.3924] device[0x563abbcca400] (wlp2s0): add_pending_action (1): 'queued state change to disconnected'
2017-01-27 13:52:26 +01:00
FALSE /* cannot assert, because of how recheck_available() first clears
the call-id and postpones removing the pending-action. */);
}
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
}
core: consolidate auto-activation recheck signals Add a generic signal that devices can use to indicate that something material in the network situation changed, and that auto-activation may now be possible. This reduces specific knowledge of device types in the policy.
2014-02-24 18:10:18 -06:00
void
nm_device_emit_recheck_auto_activate (NMDevice *self)
{
g_signal_emit (self, signals[RECHECK_AUTO_ACTIVATE], 0);
}
2008-05-29 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (dnsmasq_state_changed_cb): new function; fail the connection if something happens to dnsmasq - (nm_device_new_ip4_shared_config): new function; create a new ip4-config for shared connections. Shared connections always use a fixed static IP address. - (real_act_stage4_get_ip4_config): handle shared connections; fix autoip connections by actually using the returned ip4-config and not leaking it - (nm_device_activate_stage5_ip_config_commit): start dnsmasq for shared connections - (nm_device_deactivate_quickly, nm_device_dispose): terminate dnsmasq if its active git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3711 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-29 20:58:52 +00:00
static void
dnsmasq_state_changed_cb (NMDnsMasqManager *manager, guint32 status, gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
switch (status) {
case NM_DNSMASQ_STATUS_DEAD:
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_SHARED_START_FAILED);
2008-05-29 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (dnsmasq_state_changed_cb): new function; fail the connection if something happens to dnsmasq - (nm_device_new_ip4_shared_config): new function; create a new ip4-config for shared connections. Shared connections always use a fixed static IP address. - (real_act_stage4_get_ip4_config): handle shared connections; fix autoip connections by actually using the returned ip4-config and not leaking it - (nm_device_activate_stage5_ip_config_commit): start dnsmasq for shared connections - (nm_device_deactivate_quickly, nm_device_dispose): terminate dnsmasq if its active git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3711 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-29 20:58:52 +00:00
break;
default:
break;
}
}
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
/*****************************************************************************/
static gboolean
activation_source_handle_cb4 (gpointer user_data)
{
activation_source_handle_cb (user_data, AF_INET);
return G_SOURCE_REMOVE;
}
static gboolean
activation_source_handle_cb6 (gpointer user_data)
{
activation_source_handle_cb (user_data, AF_INET6);
return G_SOURCE_REMOVE;
}
static ActivationHandleData *
activation_source_get_by_family (NMDevice *self,
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
int addr_family,
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
GSourceFunc *out_idle_func)
core: don't schedule same activation stage multiple times Fix issues with crappy wifi drivers which send a stream of associate events before NM can schedule the next activation stage, which actually scheduled *multiple* next stages. Only allow one stage to be scheduled at at time, and don't schedule the same stage again if it's already next up to the plate.
2009-03-23 17:36:52 -04:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
switch (addr_family) {
case AF_INET6:
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
NM_SET_OUT (out_idle_func, activation_source_handle_cb6);
return &priv->act_handle6;
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
case AF_INET:
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
NM_SET_OUT (out_idle_func, activation_source_handle_cb4);
return &priv->act_handle4;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
g_return_val_if_reached (NULL);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
}
static void
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
activation_source_clear (NMDevice *self,
int addr_family)
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
{
ActivationHandleData *act_data;
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
act_data = activation_source_get_by_family (self, addr_family, NULL);
core: don't schedule same activation stage multiple times Fix issues with crappy wifi drivers which send a stream of associate events before NM can schedule the next activation stage, which actually scheduled *multiple* next stages. Only allow one stage to be scheduled at at time, and don't schedule the same stage again if it's already next up to the plate.
2009-03-23 17:36:52 -04:00
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
if (act_data->id) {
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
_LOGD (LOGD_DEVICE, "activation-stage: clear %s,v%c (id %u)",
_activation_func_to_string (act_data->func),
nm_utils_addr_family_to_char (addr_family),
act_data->id);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
nm_clear_g_source (&act_data->id);
act_data->func = NULL;
core: don't schedule same activation stage multiple times Fix issues with crappy wifi drivers which send a stream of associate events before NM can schedule the next activation stage, which actually scheduled *multiple* next stages. Only allow one stage to be scheduled at at time, and don't schedule the same stage again if it's already next up to the plate.
2009-03-23 17:36:52 -04:00
}
}
static void
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
activation_source_handle_cb (NMDevice *self,
int addr_family)
core: don't schedule same activation stage multiple times Fix issues with crappy wifi drivers which send a stream of associate events before NM can schedule the next activation stage, which actually scheduled *multiple* next stages. Only allow one stage to be scheduled at at time, and don't schedule the same stage again if it's already next up to the plate.
2009-03-23 17:36:52 -04:00
{
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
ActivationHandleData *act_data, a;
core: don't schedule same activation stage multiple times Fix issues with crappy wifi drivers which send a stream of associate events before NM can schedule the next activation stage, which actually scheduled *multiple* next stages. Only allow one stage to be scheduled at at time, and don't schedule the same stage again if it's already next up to the plate.
2009-03-23 17:36:52 -04:00
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
act_data = activation_source_get_by_family (self, addr_family, NULL);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
g_return_if_fail (act_data->id);
g_return_if_fail (act_data->func);
a = *act_data;
act_data->func = NULL;
act_data->id = 0;
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
_LOGD (LOGD_DEVICE, "activation-stage: invoke %s,v%c (id %u)",
_activation_func_to_string (a.func),
nm_utils_addr_family_to_char (addr_family),
a.id);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
a.func (self);
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
_LOGD (LOGD_DEVICE, "activation-stage: complete %s,v%c (id %u)",
_activation_func_to_string (a.func),
nm_utils_addr_family_to_char (addr_family),
a.id);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
}
static void
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
activation_source_schedule (NMDevice *self, ActivationHandleFunc func, int addr_family)
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
{
ActivationHandleData *act_data;
GSourceFunc source_func;
guint new_id = 0;
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
act_data = activation_source_get_by_family (self, addr_family, &source_func);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
device: fix activation_source_schedule() for rescheduling the same function Fixes: 78ca961c0fd0e5b563e33306299bd1058fa2e289
2016-12-08 13:24:42 +01:00
if (act_data->id && act_data->func == func) {
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
/* Don't bother rescheduling the same function that's about to
* run anyway. Fixes issues with crappy wireless drivers sending
* streams of associate events before NM has had a chance to process
* the first one.
*/
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
_LOGD (LOGD_DEVICE, "activation-stage: already scheduled %s,v%c (id %u)",
_activation_func_to_string (func),
nm_utils_addr_family_to_char (addr_family),
act_data->id);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
return;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
new_id = g_idle_add (source_func, self);
if (act_data->id) {
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
_LOGW (LOGD_DEVICE, "activation-stage: schedule %s,v%c which replaces %s,v%c (id %u -> %u)",
_activation_func_to_string (func),
nm_utils_addr_family_to_char (addr_family),
_activation_func_to_string (act_data->func),
nm_utils_addr_family_to_char (addr_family),
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
act_data->id, new_id);
nm_clear_g_source (&act_data->id);
} else {
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
_LOGD (LOGD_DEVICE, "activation-stage: schedule %s,v%c (id %u)",
_activation_func_to_string (func),
nm_utils_addr_family_to_char (addr_family),
new_id);
core: don't schedule same activation stage multiple times Fix issues with crappy wifi drivers which send a stream of associate events before NM can schedule the next activation stage, which actually scheduled *multiple* next stages. Only allow one stage to be scheduled at at time, and don't schedule the same stage again if it's already next up to the plate.
2009-03-23 17:36:52 -04:00
}
device: don't complain about repeated schedules of the same activation stage Can easily happend with a storm of DHCP responses or RAs before the idle handler has a chance to run. https://bugzilla.redhat.com/show_bug.cgi?id=1269520
2015-10-07 15:19:21 +02:00
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
act_data->func = func;
act_data->id = new_id;
core: don't schedule same activation stage multiple times Fix issues with crappy wifi drivers which send a stream of associate events before NM can schedule the next activation stage, which actually scheduled *multiple* next stages. Only allow one stage to be scheduled at at time, and don't schedule the same stage again if it's already next up to the plate.
2009-03-23 17:36:52 -04:00
}
device: postpone updates of IP configuration when a commit is pending When a new dynamic configuration is received, it is stored in a member of private structure (e.g. @dhcp6_ip6_config) and a commit is scheduled. Before the commit is executed, an update_ipx_config() could be called and it would change the configuration before it is committed. This race condition causes failures in assigning the addresses received through DHCPv6 when the internal client is used (but potentially other clients and methods are affected). To fix it, postpone updates of IP configurations when a commit is already pending.
2016-04-28 22:48:39 +02:00
static gboolean
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
activation_source_is_scheduled (NMDevice *self,
ActivationHandleFunc func,
int addr_family)
device: postpone updates of IP configuration when a commit is pending When a new dynamic configuration is received, it is stored in a member of private structure (e.g. @dhcp6_ip6_config) and a commit is scheduled. Before the commit is executed, an update_ipx_config() could be called and it would change the configuration before it is committed. This race condition causes failures in assigning the addresses received through DHCPv6 when the internal client is used (but potentially other clients and methods are affected). To fix it, postpone updates of IP configurations when a commit is already pending.
2016-04-28 22:48:39 +02:00
{
ActivationHandleData *act_data;
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
act_data = activation_source_get_by_family (self, addr_family, NULL);
device: postpone updates of IP configuration when a commit is pending When a new dynamic configuration is received, it is stored in a member of private structure (e.g. @dhcp6_ip6_config) and a commit is scheduled. Before the commit is executed, an update_ipx_config() could be called and it would change the configuration before it is committed. This race condition causes failures in assigning the addresses received through DHCPv6 when the internal client is used (but potentially other clients and methods are affected). To fix it, postpone updates of IP configurations when a commit is already pending.
2016-04-28 22:48:39 +02:00
return act_data->func == func;
}
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
/*****************************************************************************/
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
static void
device: fix activating slave device when stage1 delays action When activating for example a team device which is to be enslaved to a bridge, nm_device_activate_stage1_device_prepare() will postpone stage 2. In that case, we didn't register the "master-ready" of the team device and thus never progressed the slave from stage2. Reproduce: # nmcli connection delete t-br0 # nmcli connection delete t-team0 nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1 nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0 nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge nmcli connection up t-team0
2015-10-01 16:48:32 +02:00
master_ready (NMDevice *self,
NMActiveConnection *active)
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
NMActiveConnection *master_connection;
NMDevice *master;
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
device: fix activating slave device when stage1 delays action When activating for example a team device which is to be enslaved to a bridge, nm_device_activate_stage1_device_prepare() will postpone stage 2. In that case, we didn't register the "master-ready" of the team device and thus never progressed the slave from stage2. Reproduce: # nmcli connection delete t-br0 # nmcli connection delete t-team0 nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1 nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0 nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge nmcli connection up t-team0
2015-10-01 16:48:32 +02:00
g_return_if_fail (priv->state == NM_DEVICE_STATE_PREPARE);
g_return_if_fail (!priv->master_ready_handled);
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
/* Notify a master device that it has a new slave */
device: fix activating slave device when stage1 delays action When activating for example a team device which is to be enslaved to a bridge, nm_device_activate_stage1_device_prepare() will postpone stage 2. In that case, we didn't register the "master-ready" of the team device and thus never progressed the slave from stage2. Reproduce: # nmcli connection delete t-br0 # nmcli connection delete t-team0 nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1 nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0 nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge nmcli connection up t-team0
2015-10-01 16:48:32 +02:00
g_return_if_fail (nm_active_connection_get_master_ready (active));
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
master_connection = nm_active_connection_get_master (active);
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
device: fix activating slave device when stage1 delays action When activating for example a team device which is to be enslaved to a bridge, nm_device_activate_stage1_device_prepare() will postpone stage 2. In that case, we didn't register the "master-ready" of the team device and thus never progressed the slave from stage2. Reproduce: # nmcli connection delete t-br0 # nmcli connection delete t-team0 nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1 nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0 nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge nmcli connection up t-team0
2015-10-01 16:48:32 +02:00
priv->master_ready_handled = TRUE;
nm_clear_g_signal_handler (active, &priv->master_ready_id);
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
master = nm_active_connection_get_device (master_connection);
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "master connection ready; master device %s",
device: fix crash in master_ready() logging unset priv->master Fixes: f45f702a5ece358bf8cc075dc3a2d2f04f99b4d7
2015-12-07 21:35:20 +01:00
nm_device_get_iface (master));
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
if (priv->master && priv->master != master)
nm_device_master_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
/* If the master didn't change, add-slave only rechecks whether to assume a connection. */
nm_device_master_add_slave (master,
self,
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
!nm_device_sys_iface_state_is_external_or_assume (self));
device: fix activating slave device when stage1 delays action When activating for example a team device which is to be enslaved to a bridge, nm_device_activate_stage1_device_prepare() will postpone stage 2. In that case, we didn't register the "master-ready" of the team device and thus never progressed the slave from stage2. Reproduce: # nmcli connection delete t-br0 # nmcli connection delete t-team0 nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1 nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0 nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge nmcli connection up t-team0
2015-10-01 16:48:32 +02:00
}
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
device: fix activating slave device when stage1 delays action When activating for example a team device which is to be enslaved to a bridge, nm_device_activate_stage1_device_prepare() will postpone stage 2. In that case, we didn't register the "master-ready" of the team device and thus never progressed the slave from stage2. Reproduce: # nmcli connection delete t-br0 # nmcli connection delete t-team0 nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1 nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0 nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge nmcli connection up t-team0
2015-10-01 16:48:32 +02:00
static void
master_ready_cb (NMActiveConnection *active,
GParamSpec *pspec,
NMDevice *self)
{
master_ready (self, active);
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
nm_device_activate_schedule_stage2_device_config (self);
}
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
static void
lldp_neighbors_changed (NMLldpListener *lldp_listener, GParamSpec *pspec,
gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_LLDP_NEIGHBORS);
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
}
static gboolean
lldp_rx_enabled (NMDevice *self)
{
NMConnection *connection;
NMSettingConnection *s_con;
NMSettingConnectionLldp lldp = NM_SETTING_CONNECTION_LLDP_DEFAULT;
connection = nm_device_get_applied_connection (self);
g_return_val_if_fail (connection, FALSE);
s_con = nm_connection_get_setting_connection (connection);
g_return_val_if_fail (s_con, FALSE);
lldp = nm_setting_connection_get_lldp (s_con);
if (lldp == NM_SETTING_CONNECTION_LLDP_DEFAULT) {
gs_free char *value = NULL;
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
"connection.lldp",
self);
lldp = _nm_utils_ascii_str_to_int64 (value, 10,
NM_SETTING_CONNECTION_LLDP_DEFAULT,
NM_SETTING_CONNECTION_LLDP_ENABLE_RX,
NM_SETTING_CONNECTION_LLDP_DEFAULT);
if (lldp == NM_SETTING_CONNECTION_LLDP_DEFAULT)
lldp = NM_SETTING_CONNECTION_LLDP_DISABLE;
}
return lldp == NM_SETTING_CONNECTION_LLDP_ENABLE_RX;
}
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
static NMActStageReturn
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
act_stage1_prepare (NMDevice *self, NMDeviceStateReason *out_failure_reason)
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
{
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
return NM_ACT_STAGE_RETURN_SUCCESS;
bonding: enslave/release bonding slaves in activation/deactivation Code is written generic enough to allow easy addition of further master/slave relationships such as bridging relations. Signed-off-by: Thomas Graf <tgraf@redhat.com> (whitespace cleanups and libnl compat by dcbw)
2011-10-18 13:48:48 +02:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
/*
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
* activate_stage1_device_prepare
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
* Prepare for device activation
*
*/
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static void
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activate_stage1_device_prepare (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
NMActStageReturn ret = NM_ACT_STAGE_RETURN_SUCCESS;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_NONE);
_set_ip_state (self, AF_INET6, IP_NONE);
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
core: export ActiveConnection before handing it to the device (bgo #723783) The AC doesn't get a D-Bus path until it's exported, but that happens after it's handed to the Device it will be activated on. The Device emits a PropertyChanged event when it's handed the AC, but it ignores ACs that aren't exported yet. Thus when activating, the Device doesn't emit the AC's path at all in the ActiveConnection property because it's NULL. Fix that by exporting the AC immediately before starting activation with it. Second, move the notification of the Device.ActiveConnection property to be emitted along with the state change to PREPARE instead of long before it. While we don't guarantee signal ordering in general, this seems like a more correct ordering. https://bugzilla.gnome.org/show_bug.cgi?id=723783
2014-03-20 11:22:19 -05:00
/* Notify the new ActiveConnection along with the state change */
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
priv->act_request_public = TRUE;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_ACTIVE_CONNECTION);
core: export ActiveConnection before handing it to the device (bgo #723783) The AC doesn't get a D-Bus path until it's exported, but that happens after it's handed to the Device it will be activated on. The Device emits a PropertyChanged event when it's handed the AC, but it ignores ACs that aren't exported yet. Thus when activating, the Device doesn't emit the AC's path at all in the ActiveConnection property because it's NULL. Fix that by exporting the AC immediately before starting activation with it. Second, move the notification of the Device.ActiveConnection property to be emitted along with the state change to PREPARE instead of long before it. While we don't guarantee signal ordering in general, this seems like a more correct ordering. https://bugzilla.gnome.org/show_bug.cgi?id=723783
2014-03-20 11:22:19 -05:00
2008-07-11 Dan Williams <dcbw@redhat.com> Modify the NMDevice::state-changed signal to include the previous state and reason. Enables the applet to provide more information why device activation failed. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3819 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-11 10:28:53 +00:00
nm_device_state_changed (self, NM_DEVICE_STATE_PREPARE, NM_DEVICE_STATE_REASON_NONE);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
/* Assumed connections were already set up outside NetworkManager */
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (!nm_device_sys_iface_state_is_external_or_assume (self)) {
device: mark uses of device's state-reason with nm_device_state_reason_check() The state-change of a device has a reason argument, which is mostly for information only. There are many places in code that are the source of a state-reason. Mostly these are calls to: - nm_device_state_changed() - nm_device_queue_state() - nm_device_queue_recheck_available() - nm_device_set_unmanaged_by_*() - nm_device_master_release_one_slave() - nm_device_ip_method_failed() - nm_modem_emit_prepare_result() - nm_modem_emit_ppp_failed() - nm_manager_deactivate_connection() - NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_*); However, there are a few places in code that look at the reason to decide how to proceed. I think this is a bad pattern, because cause and effect are decoupled and it gets hard to understand where a certain reason is set and what consequences that has. Add a nop-function nm_device_state_reason_check() to mark all uses of the device state reason that derive decisions from it. That is, highlight the "effect" part.
2017-02-23 15:19:03 +01:00
NMDeviceStateReason failure_reason = NM_DEVICE_STATE_REASON_NONE;
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
ret = NM_DEVICE_GET_CLASS (self)->act_stage1_prepare (self, &failure_reason);
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
if (ret == NM_ACT_STAGE_RETURN_POSTPONE) {
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
} else if (ret == NM_ACT_STAGE_RETURN_FAILURE) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, failure_reason);
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
}
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
g_return_if_fail (ret == NM_ACT_STAGE_RETURN_SUCCESS);
2006-1-3 Dan Williams <dcbw@redhat.com> * src/NetworkManager.c - Move link-checking/probing into the device subclasses themselves * src/nm-device.[ch] src/nm-device-802-11-wireless.c src/nm-device-802-3-ethernet.c - Do periodic link checking in device subclasses rather than being triggered from NetworkManager.c - discover_wireless_capabilities -> get_wireless_capabilities - discover_generic_capabilities -> get_generic_capabilities - Device subclass activation routines now return a value of type NMActStageReturn to indicate what step to perform next - Devices now override stage4_get_ip4_config if they choose git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1249 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:07:07 +00:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: fix activating slave device when stage1 delays action When activating for example a team device which is to be enslaved to a bridge, nm_device_activate_stage1_device_prepare() will postpone stage 2. In that case, we didn't register the "master-ready" of the team device and thus never progressed the slave from stage2. Reproduce: # nmcli connection delete t-br0 # nmcli connection delete t-team0 nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1 nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0 nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge nmcli connection up t-team0
2015-10-01 16:48:32 +02:00
nm_device_activate_schedule_stage2_device_config (self);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
/*
* nm_device_activate_schedule_stage1_device_prepare
*
* Prepare a device for activation
*
*/
void
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
nm_device_activate_schedule_stage1_device_prepare (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
NMDevicePrivate *priv;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
g_return_if_fail (NM_IS_DEVICE (self));
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
priv = NM_DEVICE_GET_PRIVATE (self);
g_return_if_fail (priv->act_request);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activation_source_schedule (self, activate_stage1_device_prepare, AF_INET);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
2006-1-3 Dan Williams <dcbw@redhat.com> * src/NetworkManager.c - Move link-checking/probing into the device subclasses themselves * src/nm-device.[ch] src/nm-device-802-11-wireless.c src/nm-device-802-3-ethernet.c - Do periodic link checking in device subclasses rather than being triggered from NetworkManager.c - discover_wireless_capabilities -> get_wireless_capabilities - discover_generic_capabilities -> get_generic_capabilities - Device subclass activation routines now return a value of type NMActStageReturn to indicate what step to perform next - Devices now override stage4_get_ip4_config if they choose git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1249 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:07:07 +00:00
static NMActStageReturn
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
act_stage2_config (NMDevice *self, NMDeviceStateReason *out_failure_reason)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
2006-1-3 Dan Williams <dcbw@redhat.com> * src/NetworkManager.c - Move link-checking/probing into the device subclasses themselves * src/nm-device.[ch] src/nm-device-802-11-wireless.c src/nm-device-802-3-ethernet.c - Do periodic link checking in device subclasses rather than being triggered from NetworkManager.c - discover_wireless_capabilities -> get_wireless_capabilities - discover_generic_capabilities -> get_generic_capabilities - Device subclass activation routines now return a value of type NMActStageReturn to indicate what step to perform next - Devices now override stage4_get_ip4_config if they choose git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1249 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:07:07 +00:00
return NM_ACT_STAGE_RETURN_SUCCESS;
}
device: reapply connection.lldp property
2017-03-06 17:48:01 +01:00
static void
lldp_init (NMDevice *self, gboolean restart)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->ifindex > 0 && lldp_rx_enabled (self)) {
gs_free_error GError *error = NULL;
gconstpointer addr;
size_t addr_length;
if (priv->lldp_listener) {
if (restart && nm_lldp_listener_is_running (priv->lldp_listener))
nm_lldp_listener_stop (priv->lldp_listener);
} else {
priv->lldp_listener = nm_lldp_listener_new ();
g_signal_connect (priv->lldp_listener,
"notify::" NM_LLDP_LISTENER_NEIGHBORS,
G_CALLBACK (lldp_neighbors_changed),
self);
}
if (!nm_lldp_listener_is_running (priv->lldp_listener)) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
addr = nm_platform_link_get_address (nm_device_get_platform (self), priv->ifindex, &addr_length);
device: reapply connection.lldp property
2017-03-06 17:48:01 +01:00
if (nm_lldp_listener_start (priv->lldp_listener, nm_device_get_ifindex (self), &error))
_LOGD (LOGD_DEVICE, "LLDP listener %p started", priv->lldp_listener);
else {
_LOGD (LOGD_DEVICE, "LLDP listener %p could not be started: %s",
priv->lldp_listener, error->message);
}
}
} else {
if (priv->lldp_listener)
nm_lldp_listener_stop (priv->lldp_listener);
}
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
/*
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
* activate_stage2_device_config
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
* Determine device parameters and set those on the device, ie
2007-06-27 Dan Williams <dcbw@redhat.com> * Make SSIDs GByteArrays everywhere * Rename "essid" -> "ssid" everywhere that's appropriate * Refcount activation_ap member of the 802.11 wireless device class git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2620 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-27 16:18:52 +00:00
* for wireless devices, set SSID, keys, etc.
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
*/
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static void
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activate_stage2_device_config (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
2007-01-04 Dan Williams <dcbw@redhat.com> Threading removal related cleanups: - Use the glib default main context. Remove the device main context member from NMDevice, and the main_context member from NMData. Change all the idle and timeout scheduler functions to use plain g_idle_add() and g_timeout_add(). - As a side-effect of the first change, nm_dbus_manager_get() no longer takes an argument; fix that up too. - Remove all locking, which is useless since we no longer use threads. For example, nm_get_device_by_iface_locked() has been removed. The global device list lock, the AP List lock, and all static locks in NetworkManagerPolicy.c have been removed. The locking utility functions in NetworkManagerUtils.c have also been removed. - Other cleanups in spacing and code style git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2205 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-01-04 12:06:26 +00:00
NMActStageReturn ret;
2008-08-18 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h introspection/nm-device.xml - Add a "missing firmware" device state reason * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_up_down): add a no_firmware argument - (nm_system_device_set_up_down_with_iface): if the result of setting IFF_UP is ENOENT, that almost always means missing firmware * src/backends/NetworkManagerGeneric.c src/nm-device-ethernet.c src/nm-device-private.h src/nm-device-wifi.c src/nm-device.c src/nm-device.h src/nm-hso-gsm-device.c src/vpn-manager/nm-vpn-connection.c - Pass no_firmware along; check it where appropriate git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3983 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-18 18:29:47 +00:00
gboolean no_firmware = FALSE;
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
CList *iter;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2008-07-11 Dan Williams <dcbw@redhat.com> Modify the NMDevice::state-changed signal to include the previous state and reason. Enables the applet to provide more information why device activation failed. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3819 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-11 10:28:53 +00:00
nm_device_state_changed (self, NM_DEVICE_STATE_CONFIG, NM_DEVICE_STATE_REASON_NONE);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
/* Assumed connections were already set up outside NetworkManager */
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (!nm_device_sys_iface_state_is_external_or_assume (self)) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NMDeviceStateReason failure_reason = NM_DEVICE_STATE_REASON_NONE;
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
if (!nm_device_bring_up (self, FALSE, &no_firmware)) {
if (no_firmware)
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_FIRMWARE_MISSING);
else
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_CONFIG_FAILED);
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
}
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
ret = NM_DEVICE_GET_CLASS (self)->act_stage2_config (self, &failure_reason);
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
if (ret == NM_ACT_STAGE_RETURN_POSTPONE)
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
else if (ret == NM_ACT_STAGE_RETURN_FAILURE) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, failure_reason);
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
}
g_assert (ret == NM_ACT_STAGE_RETURN_SUCCESS);
2007-03-12 Dan Williams <dcbw@redhat.com> Get rid of 2 second poll of sysfs 'carrier' file for wired devices. Useless for non-carrier-detect capable devices, and useless for carrier-detect devices since we get notifications from netlink about carrier status anyway. * src/nm-device-802-3-ethernet.c - remove 'link_source_id' member from private data - (probe_link): remove and collapse into real_update_link() - (nm_device_802_3_periodic_update): remove - (real_is_up): check for sup_iface rather than link_source_id - (real_bring_up): return gboolean for success/fail; require that sup_iface be valid for device bringup to succeed - (real_bring_down): zero out link signal ids * src/nm-device.c - (nm_device_activate_stage2_device_config): fail activation if device bringup fails - (real_act_stage4_get_ip4_config): fail activation if device bringup fails - (nm_device_bring_up): return success/fail * src/nm-device.h - bring_up now returns success/fail * src/nm-device-802-11-wireless.c - (real_bring_up): return success from bringup git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2464 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-03-12 04:49:29 +00:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
/* If we have slaves that aren't yet enslaved, do that now */
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
c_list_for_each (iter, &priv->slaves) {
SlaveInfo *info = c_list_entry (iter, SlaveInfo, lst_slave);
devices: don't allow assuming a slave before its master The process of activating a slave requires that its master have an NMActiveConnection. So don't allow generating a connection on a slave until we have generated the connection on the master.
2014-06-05 13:31:46 -04:00
NMDeviceState slave_state = nm_device_get_state (info->slave);
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
devices: don't allow assuming a slave before its master The process of activating a slave requires that its master have an NMActiveConnection. So don't allow generating a connection on a slave until we have generated the connection on the master.
2014-06-05 13:31:46 -04:00
if (slave_state == NM_DEVICE_STATE_IP_CONFIG)
device/trivial: rename master related function of nm-device We have the master/slave related functions - for master device: - nm_device_master_add_slave() - nm_device_master_release_slaves() - nm_device_release_one_slave() - nm_device_enslave_slave() - for slave device: - nm_device_slave_notify_enslave() - nm_device_slave_notify_release() Rename the two that didn't match the pattern to - nm_device_master_release_one_slave() - nm_device_master_enslave_slave()
2015-08-06 14:37:12 +02:00
nm_device_master_enslave_slave (self, info->slave, nm_device_get_applied_connection (info->slave));
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
else if ( priv->act_request
&& nm_device_sys_iface_state_is_external (self)
devices: don't allow assuming a slave before its master The process of activating a slave requires that its master have an NMActiveConnection. So don't allow generating a connection on a slave until we have generated the connection on the master.
2014-06-05 13:31:46 -04:00
&& slave_state <= NM_DEVICE_STATE_DISCONNECTED)
nm_device_queue_recheck_assume (info->slave);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
device: reapply connection.lldp property
2017-03-06 17:48:01 +01:00
lldp_init (self, TRUE);
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
nm_device_activate_schedule_stage3_ip_config_start (self);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
/*
* nm_device_activate_schedule_stage2_device_config
*
* Schedule setup of the hardware device
*
*/
void
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
nm_device_activate_schedule_stage2_device_config (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
NMDevicePrivate *priv;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
g_return_if_fail (NM_IS_DEVICE (self));
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
priv = NM_DEVICE_GET_PRIVATE (self);
g_return_if_fail (priv->act_request);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: handle master-ready before scheduling stage2 Don't handle master-ready at the beginning of stage2, but instead while scheduling (and then possibly delaying the scheduling of stage2). This seems more idiomatic: When inside a stage and your part is done: call schedule-next-stage. That is, always schedule the next stage, not the current one. schedule-next-stage then might delay to really scheduling until the device is ready for the next state. Fixes: 85ac903bb8010409c4010ba09c621780b385b9b5
2015-10-06 12:03:51 +02:00
if (!priv->master_ready_handled) {
NMActiveConnection *active = NM_ACTIVE_CONNECTION (priv->act_request);
device: fail slave activation if master is deactivating When the master connection deactivates, we also fail slave connections; but if the master deactivation happens just before a slave reaches the PREPARE state, we failed to notice it and keep the slave stuck without chance of progressing. Fix this.
2016-06-29 14:20:02 +02:00
NMActiveConnection *master;
device: handle master-ready before scheduling stage2 Don't handle master-ready at the beginning of stage2, but instead while scheduling (and then possibly delaying the scheduling of stage2). This seems more idiomatic: When inside a stage and your part is done: call schedule-next-stage. That is, always schedule the next stage, not the current one. schedule-next-stage then might delay to really scheduling until the device is ready for the next state. Fixes: 85ac903bb8010409c4010ba09c621780b385b9b5
2015-10-06 12:03:51 +02:00
device: fail slave activation if master is deactivating When the master connection deactivates, we also fail slave connections; but if the master deactivation happens just before a slave reaches the PREPARE state, we failed to notice it and keep the slave stuck without chance of progressing. Fix this.
2016-06-29 14:20:02 +02:00
master = nm_active_connection_get_master (active);
if (!master) {
device: assert that master-ready handler is not scheduled in schedule_stage2_device_config()
2015-10-06 14:18:48 +02:00
g_warn_if_fail (!priv->master_ready_id);
device: handle master-ready before scheduling stage2 Don't handle master-ready at the beginning of stage2, but instead while scheduling (and then possibly delaying the scheduling of stage2). This seems more idiomatic: When inside a stage and your part is done: call schedule-next-stage. That is, always schedule the next stage, not the current one. schedule-next-stage then might delay to really scheduling until the device is ready for the next state. Fixes: 85ac903bb8010409c4010ba09c621780b385b9b5
2015-10-06 12:03:51 +02:00
priv->master_ready_handled = TRUE;
device: assert that master-ready handler is not scheduled in schedule_stage2_device_config()
2015-10-06 14:18:48 +02:00
} else {
device: handle master-ready before scheduling stage2 Don't handle master-ready at the beginning of stage2, but instead while scheduling (and then possibly delaying the scheduling of stage2). This seems more idiomatic: When inside a stage and your part is done: call schedule-next-stage. That is, always schedule the next stage, not the current one. schedule-next-stage then might delay to really scheduling until the device is ready for the next state. Fixes: 85ac903bb8010409c4010ba09c621780b385b9b5
2015-10-06 12:03:51 +02:00
/* If the master connection is ready for slaves, attach ourselves */
if (nm_active_connection_get_master_ready (active))
master_ready (self, active);
device: fail slave activation if master is deactivating When the master connection deactivates, we also fail slave connections; but if the master deactivation happens just before a slave reaches the PREPARE state, we failed to notice it and keep the slave stuck without chance of progressing. Fix this.
2016-06-29 14:20:02 +02:00
else if (nm_active_connection_get_state (master) >= NM_ACTIVE_CONNECTION_STATE_DEACTIVATING) {
_LOGD (LOGD_DEVICE, "master connection is deactivating");
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_DEPENDENCY_FAILED);
} else {
device: handle master-ready before scheduling stage2 Don't handle master-ready at the beginning of stage2, but instead while scheduling (and then possibly delaying the scheduling of stage2). This seems more idiomatic: When inside a stage and your part is done: call schedule-next-stage. That is, always schedule the next stage, not the current one. schedule-next-stage then might delay to really scheduling until the device is ready for the next state. Fixes: 85ac903bb8010409c4010ba09c621780b385b9b5
2015-10-06 12:03:51 +02:00
_LOGD (LOGD_DEVICE, "waiting for master connection to become ready");
if (priv->master_ready_id == 0) {
priv->master_ready_id = g_signal_connect (active,
"notify::" NM_ACTIVE_CONNECTION_INT_MASTER_READY,
(GCallback) master_ready_cb,
self);
}
/* Postpone */
return;
}
}
}
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activation_source_schedule (self, activate_stage2_device_config, AF_INET);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
void
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
nm_device_ip_method_failed (NMDevice *self,
int addr_family,
NMDeviceStateReason reason)
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
{
NMDevicePrivate *priv;
g_return_if_fail (NM_IS_DEVICE (self));
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
g_return_if_fail (NM_IN_SET (addr_family, AF_INET, AF_INET6));
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
_set_ip_state (self, addr_family, IP_FAIL);
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
if (get_ip_config_may_fail (self, addr_family))
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, FALSE);
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
else
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, reason);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
/* IPv4 DAD stuff */
static guint
get_ipv4_dad_timeout (NMDevice *self)
{
NMConnection *connection;
NMSettingIPConfig *s_ip4 = NULL;
gs_free char *value = NULL;
gint ret = 0;
connection = nm_device_get_applied_connection (self);
if (connection)
s_ip4 = nm_connection_get_setting_ip4_config (connection);
if (s_ip4) {
ret = nm_setting_ip_config_get_dad_timeout (s_ip4);
if (ret < 0) {
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
"ipv4.dad-timeout", self);
ret = _nm_utils_ascii_str_to_int64 (value, 10, -1,
NM_SETTING_IP_CONFIG_DAD_TIMEOUT_MAX,
-1);
ret = ret < 0 ? 0 : ret;
}
}
return ret;
}
static void
arping_data_destroy (gpointer ptr, GClosure *closure)
{
ArpingData *data = ptr;
int i;
if (data) {
for (i = 0; data->configs && data->configs[i]; i++)
g_object_unref (data->configs[i]);
g_free (data->configs);
g_slice_free (ArpingData, data);
}
}
static void
ipv4_manual_method_apply (NMDevice *self, NMIP4Config **configs, gboolean success)
{
NMIP4Config *empty;
if (success) {
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
empty = _ip4_config_new (self);
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
nm_device_activate_schedule_ip4_config_result (self, empty);
g_object_unref (empty);
} else {
device: don't necessarily fail the connection when ipv4 DAD fails Don't necessarily fail the entire connection if a duplicate IPv4 address is detected, but instead look at the may-fail property and at the outcome of IPv6. https://bugzilla.redhat.com/show_bug.cgi?id=1508001
2017-11-02 14:08:55 +01:00
nm_device_ip_method_failed (self, AF_INET,
device: add a new state-reason for DAD failures
2017-11-02 14:22:10 +01:00
NM_DEVICE_STATE_REASON_IP_ADDRESS_DUPLICATE);
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
}
}
static void
arping_manager_probe_terminated (NMArpingManager *arping_manager, ArpingData *data)
{
NMDevice *self;
NMDevicePrivate *priv;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
NMDedupMultiIter ipconf_iter;
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
const NMPlatformIP4Address *address;
gboolean result, success = TRUE;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
int i;
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
g_assert (data);
self = data->device;
priv = NM_DEVICE_GET_PRIVATE (self);
for (i = 0; data->configs && data->configs[i]; i++) {
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
nm_ip_config_iter_ip4_address_for_each (&ipconf_iter, data->configs[i], &address) {
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
result = nm_arping_manager_check_address (arping_manager, address->address);
success &= result;
_NMLOG (result ? LOGL_DEBUG : LOGL_WARN,
LOGD_DEVICE,
"IPv4 DAD result: address %s is %s",
nm_utils_inet4_ntop (address->address, NULL),
result ? "unique" : "duplicate");
}
}
data->callback (self, data->configs, success);
priv->arping.dad_list = g_slist_remove (priv->arping.dad_list, arping_manager);
nm_arping_manager_destroy (arping_manager);
}
/**
* ipv4_dad_start:
* @self: device instance
* @configs: NULL-terminated array of IPv4 configurations
* @cb: callback function
*
* Start IPv4 DAD on device @self, check addresses in @configs and call @cb
* when the procedure ends. @cb will be called in any case, even if DAD can't
* be started. @configs will be unreferenced after @cb has been called.
*/
static void
ipv4_dad_start (NMDevice *self, NMIP4Config **configs, ArpingCallback cb)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMArpingManager *arping_manager;
const NMPlatformIP4Address *address;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
NMDedupMultiIter ipconf_iter;
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
ArpingData *data;
guint timeout;
gboolean ret, addr_found;
const guint8 *hw_addr;
size_t hw_addr_len = 0;
GError *error = NULL;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
guint i;
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
g_return_if_fail (NM_IS_DEVICE (self));
g_return_if_fail (configs);
g_return_if_fail (cb);
for (i = 0, addr_found = FALSE; configs[i]; i++) {
if (nm_ip4_config_get_num_addresses (configs[i]) > 0) {
addr_found = TRUE;
break;
}
}
timeout = get_ipv4_dad_timeout (self);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
hw_addr = nm_platform_link_get_address (nm_device_get_platform (self),
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
nm_device_get_ip_ifindex (self),
&hw_addr_len);
if ( !timeout
|| !hw_addr
|| !hw_addr_len
|| !addr_found
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
|| nm_device_sys_iface_state_is_external_or_assume (self)) {
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
/* DAD not needed, signal success */
cb (self, configs, TRUE);
for (i = 0; configs[i]; i++)
g_object_unref (configs[i]);
g_free (configs);
return;
}
/* don't take additional references of @arping_manager that outlive @self.
* Otherwise, the callback can be invoked on a dangling pointer as we don't
* disconnect the handler. */
arping_manager = nm_arping_manager_new (nm_device_get_ip_ifindex (self));
priv->arping.dad_list = g_slist_append (priv->arping.dad_list, arping_manager);
data = g_slice_new0 (ArpingData);
data->configs = configs;
data->callback = cb;
data->device = self;
for (i = 0; configs[i]; i++) {
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
nm_ip_config_iter_ip4_address_for_each (&ipconf_iter, configs[i], &address)
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
nm_arping_manager_add_address (arping_manager, address->address);
}
g_signal_connect_data (arping_manager, NM_ARPING_MANAGER_PROBE_TERMINATED,
G_CALLBACK (arping_manager_probe_terminated), data,
arping_data_destroy, 0);
ret = nm_arping_manager_start_probe (arping_manager, timeout, &error);
if (!ret) {
_LOGW (LOGD_DEVICE, "arping probe failed: %s", error->message);
/* DAD could not be started, signal success */
cb (self, configs, TRUE);
priv->arping.dad_list = g_slist_remove (priv->arping.dad_list, arping_manager);
nm_arping_manager_destroy (arping_manager);
}
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
/* IPv4LL stuff */
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
static void
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
ipv4ll_cleanup (NMDevice *self)
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
if (priv->ipv4ll) {
sd_ipv4ll_set_callback (priv->ipv4ll, NULL, NULL);
sd_ipv4ll_stop (priv->ipv4ll);
priv->ipv4ll = sd_ipv4ll_unref (priv->ipv4ll);
2008-07-27 Dan Williams <dcbw@redhat.com> * src/dnsmasq-manager/nm-dnsmasq-manager.c src/nm-device.c src/ppp-manager/nm-ppp-manager.c - Ensure child process gets reaped. The child watch function may be removed from the mainloop before the child gets killed, so we have to make sure the child is reaped when it's told to die intentionally git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3857 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-27 19:42:54 +00:00
}
device: get rid of ipv4ll_timeout_remove() nm_clear_g_source() already does that.
2015-10-07 17:40:34 +02:00
nm_clear_g_source (&priv->ipv4ll_timeout);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
}
static NMIP4Config *
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
ipv4ll_get_ip4_config (NMDevice *self, guint32 lla)
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
{
NMIP4Config *config = NULL;
core: switch nm-ip4-config's NMIP[46]Address to NMPlatformIP[46]Address
2013-06-29 13:33:36 +02:00
NMPlatformIP4Address address;
core: use NMIP[46]Route in nm-ip[46]-config
2013-07-31 23:07:32 +02:00
NMPlatformIP4Route route;
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
config = _ip4_config_new (self);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
g_assert (config);
2008-07-11 Dan Williams <dcbw@redhat.com> Modify the NMDevice::state-changed signal to include the previous state and reason. Enables the applet to provide more information why device activation failed. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3819 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-11 10:28:53 +00:00
core: switch nm-ip4-config's NMIP[46]Address to NMPlatformIP[46]Address
2013-06-29 13:33:36 +02:00
memset (&address, 0, sizeof (address));
platform: properly handle IPv4 peer-addresses The peer-address (IFA_ADDRESS) can also be all-zero (0.0.0.0). That is distinct from an usual address without explicit peer-address, which implicitly has the same peer and local address. Previously, we treated an all-zero peer_address as having peer and local address equal. This is especially grave, because the peer is part of the primary key for an IPv4 address. So we not only get a property of the address wrong, but we wrongly consider two different addresses as one and the same. To properly handle these addresses, we always must explicitly set the peer.
2015-10-21 23:17:11 +02:00
nm_platform_ip4_address_set_addr (&address, lla, 16);
core/trivial: rename "source" field of addresses and routes The "source" field of NMPlatformIPRoute (now "rt_source") maps to the protocol field of the route. The source of NMPlatformIPAddress (now "addr_source") has no direct equivalent in the kernel. As their use is different, they should have different names. Also, the name "source" is used all over the place. Hence give the fields a more distinct name.
2016-04-11 13:09:52 +02:00
address.addr_source = NM_IP_CONFIG_SOURCE_IP4LL;
core: switch nm-ip4-config's NMIP[46]Address to NMPlatformIP[46]Address
2013-06-29 13:33:36 +02:00
nm_ip4_config_add_address (config, &address);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
core: add a multicast route entry for connections with link-local IPv4 address
2010-06-09 15:01:23 +02:00
/* Add a multicast route for link-local connections: destination= 224.0.0.0, netmask=240.0.0.0 */
core: use NMIP[46]Route in nm-ip[46]-config
2013-07-31 23:07:32 +02:00
memset (&route, 0, sizeof (route));
route.network = htonl (0xE0000000L);
route.plen = 4;
core/trivial: rename "source" field of addresses and routes The "source" field of NMPlatformIPRoute (now "rt_source") maps to the protocol field of the route. The source of NMPlatformIPAddress (now "addr_source") has no direct equivalent in the kernel. As their use is different, they should have different names. Also, the name "source" is used all over the place. Hence give the fields a more distinct name.
2016-04-11 13:09:52 +02:00
route.rt_source = NM_IP_CONFIG_SOURCE_IP4LL;
core: use ipv4.route-table setting for other IPv4 routes Including device-routes, default-route, DHCPv4, IPv4LL.
2017-09-28 14:40:12 +02:00
route.table_coerced = nm_platform_route_table_coerce (nm_device_get_route_table (self, AF_INET, TRUE));
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
route.metric = nm_device_get_route_metric (self, AF_INET);
core: return new route from _nm_ip_config_add_obj() Later we will need the exact instance that we just added (or the previously existing one, if the new route is already tracked).
2017-09-05 10:36:50 +02:00
nm_ip4_config_add_route (config, &route, NULL);
core: add a multicast route entry for connections with link-local IPv4 address
2010-06-09 15:01:23 +02:00
core: use NMIP[46]Route in nm-ip[46]-config
2013-07-31 23:07:32 +02:00
return config;
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
}
#define IPV4LL_NETWORK (htonl (0xA9FE0000L))
#define IPV4LL_NETMASK (htonl (0xFFFF0000L))
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
static void
nm_device_handle_ipv4ll_event (sd_ipv4ll *ll, int event, void *data)
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
{
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
NMDevice *self = data;
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
NMConnection *connection = NULL;
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
const char *method;
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
struct in_addr address;
NMIP4Config *config;
int r;
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
if (priv->act_request == NULL)
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
return;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_act_request_get_applied_connection (priv->act_request);
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
g_assert (connection);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
/* Ignore if the connection isn't an AutoIP connection */
core: don't have IP4 and IP6 configs on slaves Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
2013-10-14 10:38:56 -04:00
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP4_CONFIG);
if (g_strcmp0 (method, NM_SETTING_IP4_CONFIG_METHOD_LINK_LOCAL) != 0)
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
return;
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
switch (event) {
merge: merge branch 'systemd' into master
2015-10-07 10:07:17 +02:00
case SD_IPV4LL_EVENT_BIND:
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
r = sd_ipv4ll_get_address (ll, &address);
if (r < 0) {
_LOGE (LOGD_AUTOIP4, "invalid IPv4 link-local address received, error %d.", r);
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_AUTOIP_START_FAILED);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
return;
}
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
if ((address.s_addr & IPV4LL_NETMASK) != IPV4LL_NETWORK) {
_LOGE (LOGD_AUTOIP4, "invalid address %08x received (not link-local).", address.s_addr);
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_AUTOIP_ERROR);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
return;
}
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
config = ipv4ll_get_ip4_config (self, address.s_addr);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
if (config == NULL) {
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
_LOGE (LOGD_AUTOIP4, "failed to get IPv4LL config");
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_AUTOIP_FAILED);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
return;
}
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
if (priv->ip4_state == IP_CONF) {
device: get rid of ipv4ll_timeout_remove() nm_clear_g_source() already does that.
2015-10-07 17:40:34 +02:00
nm_clear_g_source (&priv->ipv4ll_timeout);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
nm_device_activate_schedule_ip4_config_result (self, config);
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
} else if (priv->ip4_state == IP_DONE) {
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
g_clear_object (&priv->dev_ip4_config);
priv->dev_ip4_config = g_object_ref (config);
if (!ip4_config_merge_and_apply (self, TRUE)) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGE (LOGD_AUTOIP4, "failed to update IP4 config for autoip change.");
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_AUTOIP_FAILED);
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
}
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
} else
g_assert_not_reached ();
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
g_object_unref (config);
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
break;
default:
_LOGW (LOGD_AUTOIP4, "IPv4LL address no longer valid after event %d.", event);
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_AUTOIP_FAILED);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
}
}
static gboolean
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
ipv4ll_timeout_cb (gpointer user_data)
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
if (priv->ipv4ll_timeout) {
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
_LOGI (LOGD_AUTOIP4, "IPv4LL configuration timed out.");
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
priv->ipv4ll_timeout = 0;
ipv4ll_cleanup (self);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
if (priv->ip4_state == IP_CONF)
nm_device_activate_schedule_ip4_config_timeout (self);
}
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
return FALSE;
}
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
static NMActStageReturn
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
ipv4ll_start (NMDevice *self)
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
const struct ether_addr *addr;
int ifindex, r;
size_t addr_len;
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
ipv4ll_cleanup (self);
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
r = sd_ipv4ll_new (&priv->ipv4ll);
if (r < 0) {
_LOGE (LOGD_AUTOIP4, "IPv4LL: new() failed with error %d", r);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
return NM_ACT_STAGE_RETURN_FAILURE;
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
}
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
r = sd_ipv4ll_attach_event (priv->ipv4ll, NULL, 0);
if (r < 0) {
_LOGE (LOGD_AUTOIP4, "IPv4LL: attach_event() failed with error %d", r);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
return NM_ACT_STAGE_RETURN_FAILURE;
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
}
ifindex = nm_device_get_ip_ifindex (self);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
addr = nm_platform_link_get_address (nm_device_get_platform (self), ifindex, &addr_len);
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
if (!addr || addr_len != ETH_ALEN) {
_LOGE (LOGD_AUTOIP4, "IPv4LL: can't retrieve hardware address");
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
return NM_ACT_STAGE_RETURN_FAILURE;
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
}
r = sd_ipv4ll_set_mac (priv->ipv4ll, addr);
if (r < 0) {
_LOGE (LOGD_AUTOIP4, "IPv4LL: set_mac() failed with error %d", r);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
return NM_ACT_STAGE_RETURN_FAILURE;
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
}
merge: merge branch systemd into master
2016-05-31 11:10:46 +02:00
r = sd_ipv4ll_set_ifindex (priv->ipv4ll, ifindex);
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
if (r < 0) {
merge: merge branch systemd into master
2016-05-31 11:10:46 +02:00
_LOGE (LOGD_AUTOIP4, "IPv4LL: set_ifindex() failed with error %d", r);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
return NM_ACT_STAGE_RETURN_FAILURE;
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
}
r = sd_ipv4ll_set_callback (priv->ipv4ll, nm_device_handle_ipv4ll_event, self);
if (r < 0) {
_LOGE (LOGD_AUTOIP4, "IPv4LL: set_callback() failed with error %d", r);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
return NM_ACT_STAGE_RETURN_FAILURE;
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
}
r = sd_ipv4ll_start (priv->ipv4ll);
if (r < 0) {
_LOGE (LOGD_AUTOIP4, "IPv4LL: start() failed with error %d", r);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
return NM_ACT_STAGE_RETURN_FAILURE;
ipv4ll: use internal implementation
2015-04-20 18:13:41 +02:00
}
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
_LOGI (LOGD_DEVICE | LOGD_AUTOIP4, "IPv4LL: started");
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
/* Start a timeout to bound the address attempt */
device/trivial: rename 'aipd' and 'autoip4' to 'ipv4ll'
2015-04-08 14:00:11 +02:00
priv->ipv4ll_timeout = g_timeout_add_seconds (20, ipv4ll_timeout_cb, self);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
return NM_ACT_STAGE_RETURN_POSTPONE;
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
policy: add manager for default routes and support multiple default routes Up to now, NMPolicy would iterate over all devices to find the "best" device and assign the default route to that device. A better approach is to add a default route to *all* devices that are never-default=no. The relative priority is choosen according to the route metrics. If two devices receive the same metric, we want to prefer the device that activates first. That way, the default route sticks to the same device until a better device activates or the device deactivates. Hence, the order of activation is imporant in this case (as it is already now). Also, if several devices have identical metrics, increment their metrics so that every metric is unique. This makes the routing deterministic according to what we choose as best device. A special case is assumed devices. In this case we cannot adjust the metric in face of equal metrics. Add a new singleton class NMDefaultRouteManager that has a list of all devices and their default routes. The manager will order the devices by their priority and configure the routes using platform. Also update the metric for VPN connections. Later we will track VPN routes also via NMDefaultRouteManager. For now, fix the VPN metric because otherwise VPNs would always get metric 1024 (which is usually much larger then the device metrics). https://bugzilla.gnome.org/show_bug.cgi?id=735512 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-29 00:03:47 +02:00
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
static void
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
ensure_con_ip4_config (NMDevice *self)
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
if (priv->con_ip4_config)
return;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
if (!connection)
return;
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
priv->con_ip4_config = _ip4_config_new (self);
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
nm_ip4_config_merge_setting (priv->con_ip4_config,
nm_connection_get_setting_ip4_config (connection),
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
nm_device_get_route_table (self, AF_INET, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET));
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (nm_device_sys_iface_state_is_external_or_assume (self)) {
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
/* For assumed connections ignore all addresses and routes. */
nm_ip4_config_reset_addresses (priv->con_ip4_config);
nm_ip4_config_reset_routes (priv->con_ip4_config);
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
}
}
static void
ensure_con_ip6_config (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
if (priv->con_ip6_config)
return;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
if (!connection)
return;
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
priv->con_ip6_config = _ip6_config_new (self);
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
nm_ip6_config_merge_setting (priv->con_ip6_config,
nm_connection_get_setting_ip6_config (connection),
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
nm_device_get_route_table (self, AF_INET6, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET6));
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (nm_device_sys_iface_state_is_external_or_assume (self)) {
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
/* For assumed connections ignore all addresses and routes. */
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
nm_ip6_config_reset_addresses (priv->con_ip6_config);
nm_ip6_config_reset_routes (priv->con_ip6_config);
}
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
/* DHCPv4 stuff */
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
dhcp4_cleanup (NMDevice *self, CleanupType cleanup_type, gboolean release)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
nm_clear_g_source (&priv->dhcp4.restart_id);
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
g_clear_pointer (&priv->dhcp4.pac_url, g_free);
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
if (priv->dhcp4.client) {
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Stop any ongoing DHCP transaction on this device */
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
nm_clear_g_signal_handler (priv->dhcp4.client, &priv->dhcp4.state_sigid);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_remove_pending_action (self, NM_PENDING_ACTION_DHCP4, FALSE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
if ( cleanup_type == CLEANUP_TYPE_DECONFIGURE
|| cleanup_type == CLEANUP_TYPE_REMOVED)
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
nm_dhcp_client_stop (priv->dhcp4.client, release);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
g_clear_object (&priv->dhcp4.client);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: fix dhcp4_cleanup() to clear dhcp4_client first (avoids assert accessing NM_DEVICE_DHCP4_CONFIG) dhcp4_cleanup() should first clear @dhcp4_client variables before clearing @dhcp4_config. Otherwise the following assert fails [1] and the DBUS property NM_DEVICE_DHCP4_CONFIG is set to %NULL. Analog to dhcp6_cleanup(), dhcp6_client, and NM_DEVICE_DHCP6_CONFIG. [1] backtrace: #0 0x0000003370c504e9 in g_logv (log_domain=0x4c148c "unrecognized-specs-changed", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff4710ed60) at gmessages.c:989 #1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x3370cbc89a "%s: assertion '%s' failed") at gmessages.c:1025 #2 0x0000003370c50679 in g_return_if_fail_warning (log_domain=log_domain@entry=0x4c144c "NetworkManager", pretty_function=pretty_function@entry=0x4c6140 <__PRETTY_FUNCTION__.15969> "nm_dhcp4_config_get_dbus_path", expression=expression@entry=0x4c60d9 "NM_IS_DHCP4_CONFIG (self)") at gmessages.c:1034 #3 0x000000000046b1d4 in nm_dhcp4_config_get_dbus_path (self=0x0) at nm-dhcp4-config.c:115 #4 0x0000000000434791 in get_property (object=0x9d2320, prop_id=13, value=0x9618a0, pspec=0x9bbc20) at devices/nm-device.c:7539 #5 0x0000003371c18e73 in object_get_property (value=0x9618a0, pspec=<optimized out>, object=0x9d2320) at gobject.c:1303 #6 g_object_get_property (object=0x9d2320, property_name=<optimized out>, value=0x9618a0) at gobject.c:2402 #7 0x000000000048482c in idle_id_reset (data=<optimized out>) at nm-properties-changed-signal.c:123 #8 0x0000003371c13055 in g_cclosure_marshal_VOID__PARAM (closure=0x9618a0, return_value=0xffffffff, n_param_values=0, param_values=0x7fff4710f130, invocation_hint=0x0, marshal_data=0x4b5201) at gmarshal.c:1037 #9 0x0000003371c10298 in g_closure_invoke (closure=0x2, closure@entry=0x919d00, return_value=return_value@entry=0x0, n_param_values=1192292656, param_values=0x9d2320, param_values@entry=0x7fff4710f130, invocation_hint=invocation_hint@entry=0x7fff4710f0d0) at gclosure.c:777 #10 0x0000003371c21b87 in signal_emit_unlocked_R (node=node@entry=0x919d90, detail=detail@entry=667, instance=instance@entry=0x9d2320, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff4710f130) at gsignal.c:3516 #11 0x0000003371c2a0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff4710f2c0) at gsignal.c:3330 #12 0x0000003371c2a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386 #13 0x0000003371c14945 in g_object_dispatch_properties_changed (object=0x9d2320, n_pspecs=4294967295, pspecs=0x0) at gobject.c:1047 #14 0x0000003371c17019 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0x9d2320) at gobject.c:1141 #15 g_object_notify (object=0x9d2320, property_name=property_name@entry=0x4c400f "dhcp4-config") at gobject.c:1183 #16 0x0000000000434332 in dhcp4_cleanup (self=self@entry=0x9d2320, stop=stop@entry=1, release=release@entry=0) at devices/nm-device.c:2581 #17 0x0000000000434cab in _cleanup_generic_pre (self=self@entry=0x9d2320, deconfigure=deconfigure@entry=1) at devices/nm-device.c:6448 #18 0x0000000000436db1 in nm_device_cleanup (self=self@entry=0x9d2320, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6524 #19 0x0000000000437358 in _set_state_full (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6641 #20 0x000000000043797c in nm_device_state_changed (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823 #21 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0x9d2320, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983 #22 0x000000000043a193 in nm_device_set_unmanaged_quitting (device=0x9d2320) at devices/nm-device.c:5998 #23 0x00000000004799f9 in remove_device (manager=0x9b2150, device=0x9d2320, quitting=1) at nm-manager.c:775 #24 0x000000000047bf47 in dispose (object=0x9b2150) at nm-manager.c:4935 #25 0x0000003371c14ee8 in g_object_unref (_object=0x9b2150) at gobject.c:3160 #26 0x0000000000429f43 in main (argc=1, argv=0x7fff4710f9a8) at main.c:681 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-23 10:32:32 +02:00
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
if (priv->dhcp4.config) {
nm_exported_object_clear_and_unexport (&priv->dhcp4.config);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_DHCP4_CONFIG);
core: fix dhcp4_cleanup() to clear dhcp4_client first (avoids assert accessing NM_DEVICE_DHCP4_CONFIG) dhcp4_cleanup() should first clear @dhcp4_client variables before clearing @dhcp4_config. Otherwise the following assert fails [1] and the DBUS property NM_DEVICE_DHCP4_CONFIG is set to %NULL. Analog to dhcp6_cleanup(), dhcp6_client, and NM_DEVICE_DHCP6_CONFIG. [1] backtrace: #0 0x0000003370c504e9 in g_logv (log_domain=0x4c148c "unrecognized-specs-changed", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff4710ed60) at gmessages.c:989 #1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x3370cbc89a "%s: assertion '%s' failed") at gmessages.c:1025 #2 0x0000003370c50679 in g_return_if_fail_warning (log_domain=log_domain@entry=0x4c144c "NetworkManager", pretty_function=pretty_function@entry=0x4c6140 <__PRETTY_FUNCTION__.15969> "nm_dhcp4_config_get_dbus_path", expression=expression@entry=0x4c60d9 "NM_IS_DHCP4_CONFIG (self)") at gmessages.c:1034 #3 0x000000000046b1d4 in nm_dhcp4_config_get_dbus_path (self=0x0) at nm-dhcp4-config.c:115 #4 0x0000000000434791 in get_property (object=0x9d2320, prop_id=13, value=0x9618a0, pspec=0x9bbc20) at devices/nm-device.c:7539 #5 0x0000003371c18e73 in object_get_property (value=0x9618a0, pspec=<optimized out>, object=0x9d2320) at gobject.c:1303 #6 g_object_get_property (object=0x9d2320, property_name=<optimized out>, value=0x9618a0) at gobject.c:2402 #7 0x000000000048482c in idle_id_reset (data=<optimized out>) at nm-properties-changed-signal.c:123 #8 0x0000003371c13055 in g_cclosure_marshal_VOID__PARAM (closure=0x9618a0, return_value=0xffffffff, n_param_values=0, param_values=0x7fff4710f130, invocation_hint=0x0, marshal_data=0x4b5201) at gmarshal.c:1037 #9 0x0000003371c10298 in g_closure_invoke (closure=0x2, closure@entry=0x919d00, return_value=return_value@entry=0x0, n_param_values=1192292656, param_values=0x9d2320, param_values@entry=0x7fff4710f130, invocation_hint=invocation_hint@entry=0x7fff4710f0d0) at gclosure.c:777 #10 0x0000003371c21b87 in signal_emit_unlocked_R (node=node@entry=0x919d90, detail=detail@entry=667, instance=instance@entry=0x9d2320, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff4710f130) at gsignal.c:3516 #11 0x0000003371c2a0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff4710f2c0) at gsignal.c:3330 #12 0x0000003371c2a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386 #13 0x0000003371c14945 in g_object_dispatch_properties_changed (object=0x9d2320, n_pspecs=4294967295, pspecs=0x0) at gobject.c:1047 #14 0x0000003371c17019 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0x9d2320) at gobject.c:1141 #15 g_object_notify (object=0x9d2320, property_name=property_name@entry=0x4c400f "dhcp4-config") at gobject.c:1183 #16 0x0000000000434332 in dhcp4_cleanup (self=self@entry=0x9d2320, stop=stop@entry=1, release=release@entry=0) at devices/nm-device.c:2581 #17 0x0000000000434cab in _cleanup_generic_pre (self=self@entry=0x9d2320, deconfigure=deconfigure@entry=1) at devices/nm-device.c:6448 #18 0x0000000000436db1 in nm_device_cleanup (self=self@entry=0x9d2320, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6524 #19 0x0000000000437358 in _set_state_full (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6641 #20 0x000000000043797c in nm_device_state_changed (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823 #21 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0x9d2320, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983 #22 0x000000000043a193 in nm_device_set_unmanaged_quitting (device=0x9d2320) at devices/nm-device.c:5998 #23 0x00000000004799f9 in remove_device (manager=0x9b2150, device=0x9d2320, quitting=1) at nm-manager.c:775 #24 0x000000000047bf47 in dispose (object=0x9b2150) at nm-manager.c:4935 #25 0x0000003371c14ee8 in g_object_unref (_object=0x9b2150) at gobject.c:3160 #26 0x0000000000429f43 in main (argc=1, argv=0x7fff4710f9a8) at main.c:681 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-23 10:32:32 +02:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
static gboolean
ip4_config_merge_and_apply (NMDevice *self,
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
gboolean commit)
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
{
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
NMConnection *connection;
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
gboolean success;
NMIP4Config *composite;
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
gboolean ignore_auto_routes = FALSE;
gboolean ignore_auto_dns = FALSE;
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
gboolean ignore_default_routes = FALSE;
device: minor cleanup replacing g_slist_for_each() by iteration Iterating a list is so easy, it's easier to just do it by hand, then splitting the functionality accross multiple lines.
2017-05-26 22:46:57 +02:00
GSList *iter;
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
gs_unref_ptrarray GPtrArray *ip4_dev_route_blacklist = NULL;
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
/* Apply ignore-auto-routes and ignore-auto-dns settings */
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
if (connection) {
NMSettingIPConfig *s_ip4 = nm_connection_get_setting_ip4_config (connection);
if (s_ip4) {
ignore_auto_routes = nm_setting_ip_config_get_ignore_auto_routes (s_ip4);
ignore_auto_dns = nm_setting_ip_config_get_ignore_auto_dns (s_ip4);
device: don't configure automatic default-routes if an explicit gateway is set Since commit 5c299454b49b165f645c25fd3e083c0bb747ad91 we can configure multiple default-routes. That is especially useful with IPv6 to configure multiple routers. It will also be useful, once we allow configuring manual default-routes, like regular static routes. However the problem is, that the default-route for the manual gateway and the gateway from DHCP both get the same metric. So it's undefined which route is used. To avoid that problem, and to restore previous behavior, don't accept any default-routes if a gateway is set. Fixes: 5c299454b49b165f645c25fd3e083c0bb747ad91
2017-10-24 20:46:24 +02:00
/* if the connection has an explicit gateway, we also ignore
* the default routes from other sources. */
ignore_default_routes = nm_setting_ip_config_get_never_default (s_ip4)
|| nm_setting_ip_config_get_gateway (s_ip4);
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
}
}
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
composite = _ip4_config_new (self);
core: use default value for ipvx.dns-priority Fall back to system default value for ipvx.dns-priority when it's zero in the setting. For VPNs the default value is 50; for other connections is 100, but it depends also on the content of [connection*] sections in NetworkManager.conf.
2016-05-09 16:30:41 +02:00
init_ip4_config_dns_priority (self, composite);
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
device: update external configuration before commit If the platform signaled that the external configuration changed (and thus update_ipX_config() is scheduled) and we are doing a commit of the new configuration, update priv->ext_ipX_config. Without this, the commit will remove addresses added externally but not yet captured in the external configuration. https://bugzilla.redhat.com/show_bug.cgi?id=1449873
2017-05-12 12:00:20 +02:00
if (commit) {
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
if (priv->queued_ip4_config_id)
update_ext_ip_config (self, AF_INET, FALSE, FALSE);
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
ensure_con_ip4_config (self);
device: update external configuration before commit If the platform signaled that the external configuration changed (and thus update_ipX_config() is scheduled) and we are doing a commit of the new configuration, update priv->ext_ipX_config. Without this, the commit will remove addresses added externally but not yet captured in the external configuration. https://bugzilla.redhat.com/show_bug.cgi?id=1449873
2017-05-12 12:00:20 +02:00
}
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (commit)
priv->default_route_metric_penalty_ip4_has = default_route_metric_penalty_detect (self);
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
if (priv->dev_ip4_config) {
nm_ip4_config_merge (composite, priv->dev_ip4_config,
(ignore_auto_routes ? NM_IP_CONFIG_MERGE_NO_ROUTES : 0)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
| (ignore_default_routes ? NM_IP_CONFIG_MERGE_NO_DEFAULT_ROUTES : 0)
| (ignore_auto_dns ? NM_IP_CONFIG_MERGE_NO_DNS : 0),
default_route_metric_penalty_get (self, AF_INET));
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
}
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
device: minor cleanup replacing g_slist_for_each() by iteration Iterating a list is so easy, it's easier to just do it by hand, then splitting the functionality accross multiple lines.
2017-05-26 22:46:57 +02:00
for (iter = priv->vpn4_configs; iter; iter = iter->next)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip4_config_merge (composite, iter->data, NM_IP_CONFIG_MERGE_DEFAULT, 0);
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
core: fix handling of externally added IPv4 adresses and routes on IP change The switch to combine IPv4 configs to arrive at the final config would cause externally added addresses and routes to be removed from the interface when a DHCP or LLv4 event came in, becasue the externally added details weren't cached anywhere and thus would be dropped on the IP changes.
2013-08-01 15:44:53 -05:00
if (priv->ext_ip4_config)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip4_config_merge (composite, priv->ext_ip4_config, NM_IP_CONFIG_MERGE_DEFAULT, 0);
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
wwan: split out WWAN IP4Config from device config We want to set the WWAN config last, to ensure that the configuration we use overwrites anything that pppd might have set, becuase it touches some stuff itself. That means we have to keep the WWAN config separate, since dev_ip4_config is used for DHCP and IPv4LL, which we always set first to ensure they these don't overwrite external, administrator added config (eg, priv->ext_ip4_config). This also synchronizes the IPv4 config path with the upcoming IPv6 config path.
2014-07-15 17:16:56 -05:00
/* Merge WWAN config *last* to ensure modem-given settings overwrite
* any external stuff set by pppd or other scripts.
*/
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
if (priv->wwan_ip4_config) {
nm_ip4_config_merge (composite, priv->wwan_ip4_config,
(ignore_auto_routes ? NM_IP_CONFIG_MERGE_NO_ROUTES : 0)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
| (ignore_default_routes ? NM_IP_CONFIG_MERGE_NO_DEFAULT_ROUTES : 0)
| (ignore_auto_dns ? NM_IP_CONFIG_MERGE_NO_DNS : 0),
default_route_metric_penalty_get (self, AF_INET));
device: fix handling of ignore-auto-dns and ignore-auto-routes Since commit ab6548c62134 ("device: better accept external IP changes"), ipX_config_merge_and_apply() applies the configuration static settings to an intermediate, initially empty configuration (priv->con_ipX_config) instead of the composite configuration, and thus the handling of ignore-auto-routes and ignore-auto-dns options done in nm_ipX_config_merge_setting() has no effect. Fix this by clearing the routes and the DNS information when needed before merging static settings to the composite configuration. Fixes: ab6548c62134518ba2871306397e7fb9c84260ca
2015-06-25 11:24:32 +02:00
}
default-route: also configure default-routes for assumed connections Previously for assumed connections we would never configure a default route. That has serious problems for example in the following two scenarios: - the default-route might have a limited lifetime from a previous SLAAC/accept_ra setting. In this case, once we assume the connection we must also ensure that we extend the lifetime of the default route. - the gateway could be received via DHCP/RA and it might change. If we ignore default-routes for assumed connection we miss that change. The problem is that the notion of "assumed connection" wrongly combines two conflicting goals (related bug bgo#746440): a) have an external device that is entirely unmanged by NM. b) do a seamless takeover of a previously managed connection at start, but still fully manage. This patch changes the handling of default-routes towards meaning b). https://bugzilla.redhat.com/show_bug.cgi?id=1224291
2015-05-27 11:52:39 +02:00
/* Merge user overrides into the composite config. For assumed connections,
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
* con_ip4_config is empty. */
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (priv->con_ip4_config) {
nm_ip4_config_merge (composite, priv->con_ip4_config, NM_IP_CONFIG_MERGE_DEFAULT,
default_route_metric_penalty_get (self, AF_INET));
core: fix tracking default-route during device's merge and apply If we don't commit the IP config, we must merge the currently tracked default route. Otherwise, on every non-commit call of ip4_config_merge_and_apply(), the default-route gets lost. Fixes: 77ec302714795f905301d500b9aab6c88001f32e
2017-09-18 09:22:35 +02:00
}
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
if (commit) {
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip4_config_add_dependent_routes (composite,
nm_device_get_route_table (self, AF_INET, TRUE),
nm_device_get_route_metric (self, AF_INET),
&ip4_dev_route_blacklist);
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
}
core: fix handling of externally added IPv4 adresses and routes on IP change The switch to combine IPv4 configs to arrive at the final config would cause externally added addresses and routes to be removed from the interface when a DHCP or LLv4 event came in, becasue the externally added details weren't cached anywhere and thus would be dropped on the IP changes.
2013-08-01 15:44:53 -05:00
if (commit) {
if (NM_DEVICE_GET_CLASS (self)->ip4_config_pre_commit)
NM_DEVICE_GET_CLASS (self)->ip4_config_pre_commit (self, composite);
}
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
success = nm_device_set_ip4_config (self, composite, commit, ip4_dev_route_blacklist);
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
g_object_unref (composite);
device: move setting v4_commit_first_time/v6_commit_first_time to the end of merge_and_apply()
2015-07-22 11:56:05 +02:00
if (commit)
priv->v4_commit_first_time = FALSE;
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
return success;
}
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
static gboolean
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
dhcp4_lease_change (NMDevice *self, NMIP4Config *config)
{
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
g_return_val_if_fail (config, FALSE);
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
g_clear_object (&priv->dev_ip4_config);
priv->dev_ip4_config = g_object_ref (config);
if (!ip4_config_merge_and_apply (self, TRUE)) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_DHCP4, "failed to update IPv4 config for DHCP change.");
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
return FALSE;
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
}
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
nm_dispatcher_call_device (NM_DISPATCHER_ACTION_DHCP4_CHANGE,
self,
NULL,
NULL, NULL, NULL);
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_remove_pending_action (self, NM_PENDING_ACTION_DHCP4, FALSE);
device: remove pending dhcp actions also in IP_DONE state When the IP status is IP_DONE and a DHCP transaction succeeds the 'dhcp4' and 'dhcp6' pending actions must be removed. Without this, a temporary link loss just after the activation would cause a DHCP restart and those actions would remain set, blocking the startup. https://bugzilla.redhat.com/show_bug.cgi?id=1330893
2016-05-10 16:34:50 +02:00
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
return TRUE;
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
}
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
static gboolean
dhcp4_restart_cb (gpointer user_data)
{
NMDevice *self = user_data;
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
priv->dhcp4.restart_id = 0;
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
if (dhcp4_start (self) == NM_ACT_STAGE_RETURN_FAILURE)
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
dhcp_schedule_restart (self, AF_INET, NULL);
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
return FALSE;
}
core: consolidate DHCP failure handling code
2011-10-07 12:23:35 -05:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
dhcp4_fail (NMDevice *self, gboolean timeout)
core: consolidate DHCP failure handling code
2011-10-07 12:23:35 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: consolidate DHCP failure handling code
2011-10-07 12:23:35 -05:00
device: retry DHCPv4 when a lease expires Make DHCPv4 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:00:47 +02:00
_LOGD (LOGD_DHCP4, "DHCPv4 failed: timeout %d, num tries left %u",
timeout, priv->dhcp4.num_tries_left);
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
dhcp4_cleanup (self, CLEANUP_TYPE_DECONFIGURE, FALSE);
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
/* Don't fail if there are static addresses configured on
* the device, instead retry after some time.
*/
if ( priv->ip4_state == IP_DONE
&& priv->con_ip4_config
&& nm_ip4_config_get_num_addresses (priv->con_ip4_config) > 0) {
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
dhcp_schedule_restart (self, AF_INET, "device has IP addresses");
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
return;
}
device: retry DHCPv4 when a lease expires Make DHCPv4 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:00:47 +02:00
if ( priv->dhcp4.num_tries_left == DHCP_NUM_TRIES_MAX
device: fix behavior for assumed DHCP connections When a DHCP connection is active and the DHCP server is temporarily unreachable, we restart DHCP for some times before failing the connection. From the user point of view, restarting NM (and thus assuming the existing connection) should not change this behavior. However, if NM is restarted while the server is temporarily down, at the moment we immediately fail because we consider the DHCP transaction our first try. Fix this by restoring the multiple tries when we detect that DHCP was active before because the connection is assumed.
2017-05-04 10:05:25 +02:00
&& (timeout || (priv->ip4_state == IP_CONF))
&& !priv->dhcp4.was_active)
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_activate_schedule_ip4_config_timeout (self);
device: fix behavior for assumed DHCP connections When a DHCP connection is active and the DHCP server is temporarily unreachable, we restart DHCP for some times before failing the connection. From the user point of view, restarting NM (and thus assuming the existing connection) should not change this behavior. However, if NM is restarted while the server is temporarily down, at the moment we immediately fail because we consider the DHCP transaction our first try. Fix this by restoring the multiple tries when we detect that DHCP was active before because the connection is assumed.
2017-05-04 10:05:25 +02:00
else if (priv->ip4_state == IP_DONE || priv->dhcp4.was_active) {
device: retry DHCPv4 when a lease expires Make DHCPv4 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:00:47 +02:00
/* Don't fail immediately when the lease expires but try to
* restart DHCP for a predefined number of times.
*/
if (priv->dhcp4.num_tries_left) {
priv->dhcp4.num_tries_left--;
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
dhcp_schedule_restart (self, AF_INET, "lease expired");
device: retry DHCPv4 when a lease expires Make DHCPv4 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:00:47 +02:00
} else
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_IP_CONFIG_EXPIRED);
} else
dhcp: fail the device if DHCP fails after having succeeded earlier (rh #1139326) If DHCP fails to renew or rebind a lease, fail the device since the IP config is no longer valid. Commit e2b7c482 was actually wrong for dhcp[4|6]_fail(), since (ip_state == IP_FAIL) will never be true if DHCP has ever been started, as IP_FAIL is only set from nm_device_activate_ip[4|6]_config_timeout(), which obviously will not be called in DHCP code paths if DHCP has previously succeeded.
2014-09-23 15:38:33 -05:00
g_warn_if_reached ();
core: consolidate DHCP failure handling code
2011-10-07 12:23:35 -05:00
}
device: detect duplicate IPv4 addresses when method=auto
2015-12-23 17:59:08 +01:00
static void
dhcp4_dad_cb (NMDevice *self, NMIP4Config **configs, gboolean success)
{
if (success)
nm_device_activate_schedule_ip4_config_result (self, configs[1]);
else {
device: don't necessarily fail the connection when ipv4 DAD fails Don't necessarily fail the entire connection if a duplicate IPv4 address is detected, but instead look at the may-fail property and at the outcome of IPv6. https://bugzilla.redhat.com/show_bug.cgi?id=1508001
2017-11-02 14:08:55 +01:00
nm_device_ip_method_failed (self, AF_INET,
device: add a new state-reason for DAD failures
2017-11-02 14:22:10 +01:00
NM_DEVICE_STATE_REASON_IP_ADDRESS_DUPLICATE);
device: detect duplicate IPv4 addresses when method=auto
2015-12-23 17:59:08 +01:00
}
}
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
static void
libnm, core, cli, tui: fix the capitalization of various types GLib/Gtk have mostly settled on the convention that two-letter acronyms in type names remain all-caps (eg, "IO"), but longer acronyms become initial-caps-only (eg, "Tcp"). NM was inconsistent, with most long acronyms using initial caps only (Adsl, Cdma, Dcb, Gsm, Olpc, Vlan), but others using all caps (DHCP, PPP, PPPOE, VPN). Fix libnm and src/ to use initial-caps only for all three-or-more-letter-long acronyms (and update nmcli and nmtui for the libnm changes).
2014-06-26 13:44:36 -04:00
dhcp4_state_changed (NMDhcpClient *client,
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
NMDhcpState state,
dhcp: pass IP config in state signal Just pass it in the state change signal.
2014-07-01 09:48:58 -05:00
NMIP4Config *ip4_config,
dhcp: pass DHCP options with BOUND state change The options hash is never used except for BOUND events, so don't bother caching it in the DHCP client object. Just pass it along with the BOUND state change, like the IP configuration object.
2014-07-01 12:30:29 -05:00
GHashTable *options,
device: accept multiple addresses in a DHCPv6 lease When the DHCPv6 lease received from the server contains multiple addresses, dhclient generates a new BOUND event for each of them. Instead of overwriting the previous IP6 configuration for each BOUND event, we should try to detect if the new configuration belongs to the same lease and merge its addresses with the existing one in such case. This allows NetworkManager to configure multiple addresses on an interface via DHCPv6. https://bugzilla.gnome.org/show_bug.cgi?id=681764 https://bugzilla.redhat.com/show_bug.cgi?id=1244293
2015-08-04 11:30:03 +02:00
const char *event_id,
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
gpointer user_data)
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: detect duplicate IPv4 addresses when method=auto
2015-12-23 17:59:08 +01:00
NMIP4Config *manual, **configs;
NMConnection *connection;
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
core/dhcp: use addr-family parameter for instead of boolean In many cases we want to treat IPv4 and IPv6 generically. That looks nicer if we distingish by an @addr_family integer, instead of a boolean. Replace the @is_ipv6 boolean with an @addr_family paramter. The @is_ipv6 boolean is inconsistent with other places where we use @is_ipv4 to indicate the opposite. Eventually, we should use @addr_family everywhere. Also, at the call site it's not immediately clear what TRUE/FALSE means, here AF_INET/AF_INET6 is better.
2017-09-11 11:30:48 +02:00
g_return_if_fail (nm_dhcp_client_get_addr_family (client) == AF_INET);
dhcp: pass IP config in state signal Just pass it in the state change signal.
2014-07-01 09:48:58 -05:00
g_return_if_fail (!ip4_config || NM_IS_IP4_CONFIG (ip4_config));
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DHCP4, "new DHCPv4 client state %d", state);
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
switch (state) {
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
case NM_DHCP_STATE_BOUND:
dhcp: pass IP config in state signal Just pass it in the state change signal.
2014-07-01 09:48:58 -05:00
if (!ip4_config) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_DHCP4, "failed to get IPv4 config in response to DHCP event.");
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
dhcp4_fail (self, FALSE);
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
break;
}
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
g_free (priv->dhcp4.pac_url);
priv->dhcp4.pac_url = g_strdup (g_hash_table_lookup (options, "wpad"));
nm_device_set_proxy_config (self, priv->dhcp4.pac_url);
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
nm_dhcp4_config_set_options (priv->dhcp4.config, options);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_DHCP4_CONFIG);
device: retry DHCPv4 when a lease expires Make DHCPv4 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:00:47 +02:00
priv->dhcp4.num_tries_left = DHCP_NUM_TRIES_MAX;
core: fix stale DHCPv4 information for dispatcher lease-change events (bgo #721002) dhcp4_lease_change() needs to be called *after* updating the DHCP config object to ensure that the dispatcher gets the new values.
2014-01-06 16:01:22 -06:00
device: detect duplicate IPv4 addresses when method=auto
2015-12-23 17:59:08 +01:00
if (priv->ip4_state == IP_CONF) {
connection = nm_device_get_applied_connection (self);
g_assert (connection);
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
manual = _ip4_config_new (self);
device: detect duplicate IPv4 addresses when method=auto
2015-12-23 17:59:08 +01:00
nm_ip4_config_merge_setting (manual,
nm_connection_get_setting_ip4_config (connection),
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
nm_device_get_route_table (self, AF_INET, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET));
device: detect duplicate IPv4 addresses when method=auto
2015-12-23 17:59:08 +01:00
configs = g_new0 (NMIP4Config *, 3);
configs[0] = manual;
configs[1] = g_object_ref (ip4_config);
ipv4_dad_start (self, configs, dhcp4_dad_cb);
} else if (priv->ip4_state == IP_DONE) {
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
if (dhcp4_lease_change (self, ip4_config))
nm_device_update_metered (self);
else
dhcp4_fail (self, FALSE);
core: update device 'metered' property on connection state change The metered property of a NMDevice that reaches the activated state is copied from the active connection and if its value is 'unknown' some heuristics are used to guess the actual value. When the connection is torn down the metered property is reset to 'unknown'.
2015-04-30 14:18:14 +02:00
}
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
break;
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
case NM_DHCP_STATE_TIMEOUT:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
dhcp4_fail (self, TRUE);
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
break;
core: better handle DHCP expiry/nak during initial lease acquisition (bgo #739482) When dhclient trieds to request a previous lease and the server NAKs that lease, dhclient emits the EXPIRE state. dhcpcd has also been known to emit the 'nak' state for the same reason. (systemd's DHCP client code does not push a NAK up to NetworkManager, but jumps to the REBOOT state instead, so it is unaffected by this issue.) NetworkManager saw the expire during IP configuration and treated that as full activation failure. The connection would be restarted, the same lease requested, and the same NAK delivered, over and over. Before a lease is acquired, there is (by definition) no lease to expire, so these events should be ignored. We do, however, still want to handle abnormal failures, which is why this patch splits the EXPIRE case from the FAIL case and handles them separately. https://bugzilla.gnome.org/show_bug.cgi?id=739482
2014-12-11 15:36:27 -06:00
case NM_DHCP_STATE_EXPIRE:
/* Ignore expiry before we even have a lease (NAK, old lease, etc) */
if (priv->ip4_state == IP_CONF)
break;
all: cleanup switch fall-through comments for -Wimplicit-fallthrough warning The -Wimplicit-fallthrough=3 warning is quite flexible of accepting a fall-through warning. Some comments were missing or not detected correctly. Thereby, also change all other comments to follow the exact same pattern.
2017-02-06 14:42:47 +01:00
/* fall through */
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
case NM_DHCP_STATE_DONE:
case NM_DHCP_STATE_FAIL:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
dhcp4_fail (self, FALSE);
dhcp: convert dhcp backends to classes
2010-01-12 22:09:28 -08:00
break;
default:
break;
}
}
device: introduce a global default value for ipv4.dhcp-timeout This allows the ipv4.dhcp-timeout default value to be set from user configuration. https://bugzilla.gnome.org/show_bug.cgi?id=756423
2015-10-12 10:56:16 +02:00
static int
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
get_dhcp_timeout (NMDevice *self, int addr_family)
device: introduce a global default value for ipv4.dhcp-timeout This allows the ipv4.dhcp-timeout default value to be set from user configuration. https://bugzilla.gnome.org/show_bug.cgi?id=756423
2015-10-12 10:56:16 +02:00
{
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
NMDeviceClass *klass;
NMConnection *connection;
NMSettingIPConfig *s_ip;
guint32 timeout;
device: introduce a global default value for ipv4.dhcp-timeout This allows the ipv4.dhcp-timeout default value to be set from user configuration. https://bugzilla.gnome.org/show_bug.cgi?id=756423
2015-10-12 10:56:16 +02:00
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
nm_assert (NM_IS_DEVICE (self));
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
nm_assert_addr_family (addr_family);
device: introduce a global default value for ipv4.dhcp-timeout This allows the ipv4.dhcp-timeout default value to be set from user configuration. https://bugzilla.gnome.org/show_bug.cgi?id=756423
2015-10-12 10:56:16 +02:00
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
connection = nm_device_get_applied_connection (self);
if (addr_family == AF_INET)
s_ip = nm_connection_get_setting_ip4_config (connection);
else
s_ip = nm_connection_get_setting_ip6_config (connection);
timeout = nm_setting_ip_config_get_dhcp_timeout (s_ip);
device: introduce a global default value for ipv4.dhcp-timeout This allows the ipv4.dhcp-timeout default value to be set from user configuration. https://bugzilla.gnome.org/show_bug.cgi?id=756423
2015-10-12 10:56:16 +02:00
if (timeout)
return timeout;
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
{
gs_free char *value = NULL;
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
addr_family == AF_INET
? "ipv4.dhcp-timeout"
: "ipv6.dhcp-timeout",
self);
timeout = _nm_utils_ascii_str_to_int64 (value, 10,
0, G_MAXINT32, 0);
if (timeout)
return timeout;
}
klass = NM_DEVICE_GET_CLASS (self);
if (klass->get_dhcp_timeout)
timeout = klass->get_dhcp_timeout (self, addr_family);
return timeout ?: NM_DHCP_TIMEOUT_DEFAULT;
device: introduce a global default value for ipv4.dhcp-timeout This allows the ipv4.dhcp-timeout default value to be set from user configuration. https://bugzilla.gnome.org/show_bug.cgi?id=756423
2015-10-12 10:56:16 +02:00
}
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
static NMActStageReturn
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
dhcp4_start (NMDevice *self)
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
NMSettingIPConfig *s_ip4;
core: use IP interface hardware address for IP-level operations The IP interface may have its own hardware address (like the net port for WWAN devices) and that's the hardware address that must be used for DHCP and IPv6 SLAAC, not the hardware address (if any) of the NMDevice itself. This patch does change the NMDevice hardware address property to always be the Device's hardware address, instead of the IP interface hardware address. This means that ADSL and WWAN will no longer change their hardware address to the hardware address of their IP interface. But in all these cases, the hardware address is non-existent (PPP) or transient and meaningless (WWAN/ADSL).
2014-04-10 18:02:52 -05:00
const guint8 *hw_addr;
size_t hw_addr_len = 0;
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
GByteArray *tmp = NULL;
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
NMConnection *connection;
connection = nm_device_get_applied_connection (self);
g_return_val_if_fail (connection, FALSE);
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
core: use nm_connection_get_setting_<type>() whenever possible Leads to shorter, easier to read code and improves type casting safety. Signed-off-by: Thomas Graf <tgraf@redhat.com>
2011-12-05 12:27:47 +01:00
s_ip4 = nm_connection_get_setting_ip4_config (connection);
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
/* Clear old exported DHCP options */
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
nm_exported_object_clear_and_unexport (&priv->dhcp4.config);
priv->dhcp4.config = nm_dhcp4_config_new ();
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
hw_addr = nm_platform_link_get_address (nm_device_get_platform (self), nm_device_get_ip_ifindex (self), &hw_addr_len);
core: use IP interface hardware address for IP-level operations The IP interface may have its own hardware address (like the net port for WWAN devices) and that's the hardware address that must be used for DHCP and IPv6 SLAAC, not the hardware address (if any) of the NMDevice itself. This patch does change the NMDevice hardware address property to always be the Device's hardware address, instead of the IP interface hardware address. This means that ADSL and WWAN will no longer change their hardware address to the hardware address of their IP interface. But in all these cases, the hardware address is non-existent (PPP) or transient and meaningless (WWAN/ADSL).
2014-04-10 18:02:52 -05:00
if (hw_addr_len) {
tmp = g_byte_array_sized_new (hw_addr_len);
g_byte_array_append (tmp, hw_addr, hw_addr_len);
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
}
dhcp: add DHCP lease release capability
2011-01-05 16:23:00 -06:00
/* Begin DHCP on the interface */
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
g_warn_if_fail (priv->dhcp4.client == NULL);
priv->dhcp4.client = nm_dhcp_manager_start_ip4 (nm_dhcp_manager_get (),
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
nm_netns_get_multi_idx (nm_device_get_netns (self)),
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
nm_device_get_ip_iface (self),
dhcp: pass ifindex to DHCP clients
2014-04-03 13:13:17 -05:00
nm_device_get_ip_ifindex (self),
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
tmp,
core: use nm_connection_get_id() and nm_connection_get_uuid() to simplify code
2011-03-08 13:41:28 +01:00
nm_connection_get_uuid (connection),
core: use ipv4.route-table setting for other IPv4 routes Including device-routes, default-route, DHCPv4, IPv4LL.
2017-09-28 14:40:12 +02:00
nm_device_get_route_table (self, AF_INET, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET),
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
nm_setting_ip_config_get_dhcp_send_hostname (s_ip4),
nm_setting_ip_config_get_dhcp_hostname (s_ip4),
dhcp4: send FQDN option when ipv4.dhcp-fqdn is set Modify the 3 DHCP client backends to support the new property.
2015-10-13 15:13:26 +02:00
nm_setting_ip4_config_get_dhcp_fqdn (NM_SETTING_IP4_CONFIG (s_ip4)),
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
nm_setting_ip4_config_get_dhcp_client_id (NM_SETTING_IP4_CONFIG (s_ip4)),
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
get_dhcp_timeout (self, AF_INET),
dhcp: track last IPv4 address on start for renewal Really only used by systemd because it doesn't have as good lease handling, but it's also necessary if we switch DHCP clients mid-stream (which we'll be doing later) since the new DHCP client won't have a lease file for the current IP address, and thus has nowhere to pull the current IP address from to request the same address from the DHCP server.
2014-11-03 22:35:22 -06:00
priv->dhcp_anycast_address,
NULL);
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
if (tmp)
g_byte_array_free (tmp, TRUE);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
if (!priv->dhcp4.client)
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
return NM_ACT_STAGE_RETURN_FAILURE;
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
priv->dhcp4.state_sigid = g_signal_connect (priv->dhcp4.client,
dhcp: refactor using named defines for signal names instead of plain string Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-11 14:02:24 +01:00
NM_DHCP_CLIENT_SIGNAL_STATE_CHANGED,
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
G_CALLBACK (dhcp4_state_changed),
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
self);
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_add_pending_action (self, NM_PENDING_ACTION_DHCP4, TRUE);
core: wait with "startup complete" for both IPv4 and IPv6 dynamic configuration In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until both IPv4 and IPv6 are ready. This especially has an effect on nm-online/NetworkManager-wait-online.service, which blocks until configuration of both IPv4 and IPv6 is ready. We queue a pending_action when automatic configuration starts and remove it again, when we receive an address. Before, "startup complete" was reached when either one of the two IP protocols was configured. https://bugzilla.redhat.com/show_bug.cgi?id=1086906 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-14 17:57:56 +02:00
dhcp: set @was_active flag for external activations Set the @was_active flag for external activations with DHCP, so that DHCP is retried multiple times in case of failure, as we do for managed connections when the lease expires and for assumed connections. Fixes test: renewal_gw_after_dhcp_outage_for_assumed_var1 Fixes: e3113fdc4b01d79080911b7450fc032dc0a85108
2017-05-08 08:44:51 +02:00
if (nm_device_sys_iface_state_is_external_or_assume (self))
device: fix behavior for assumed DHCP connections When a DHCP connection is active and the DHCP server is temporarily unreachable, we restart DHCP for some times before failing the connection. From the user point of view, restarting NM (and thus assuming the existing connection) should not change this behavior. However, if NM is restarted while the server is temporarily down, at the moment we immediately fail because we consider the DHCP transaction our first try. Fix this by restoring the multiple tries when we detect that DHCP was active before because the connection is assumed.
2017-05-04 10:05:25 +02:00
priv->dhcp4.was_active = TRUE;
core: factor out DHCPv4 setup
2011-01-05 14:07:32 -06:00
/* DHCP devices will be notified by the DHCP manager when stuff happens */
return NM_ACT_STAGE_RETURN_POSTPONE;
}
dhcp: add DHCP lease release capability
2011-01-05 16:23:00 -06:00
gboolean
nm_device_dhcp4_renew (NMDevice *self, gboolean release)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
g_return_val_if_fail (priv->dhcp4.client != NULL, FALSE);
dhcp: add DHCP lease release capability
2011-01-05 16:23:00 -06:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_DHCP4, "DHCPv4 lease renewal requested");
core: release DHCP lease when requested instead of always
2011-09-21 00:30:38 -05:00
dhcp: add DHCP lease release capability
2011-01-05 16:23:00 -06:00
/* Terminate old DHCP instance and release the old lease */
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
dhcp4_cleanup (self, CLEANUP_TYPE_DECONFIGURE, release);
dhcp: add DHCP lease release capability
2011-01-05 16:23:00 -06:00
/* Start DHCP again on the interface */
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
return dhcp4_start (self) != NM_ACT_STAGE_RETURN_FAILURE;
dhcp: add DHCP lease release capability
2011-01-05 16:23:00 -06:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
static GHashTable *shared_ips = NULL;
static void
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
shared_ip_release (gpointer data)
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
{
g_hash_table_remove (shared_ips, data);
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
if (!g_hash_table_size (shared_ips))
g_clear_pointer (&shared_ips, g_hash_table_unref);
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
}
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
static NMIP4Config *
shared4_new_config (NMDevice *self, NMConnection *connection)
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
{
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
NMIP4Config *config = NULL;
gboolean is_generated = FALSE;
NMSettingIPConfig *s_ip4;
NMPlatformIP4Address address = {
.addr_source = NM_IP_CONFIG_SOURCE_SHARED,
};
core: allow custom IP address ranges for Shared connections (bgo #675973) Given an IPv4 address and prefix for a shared config, figure out the DHCP address range automatically. To keep things simple we allow a max of 252 addresses (not including network address, broadcast address, and the hotspot) no matter what prefix you use, so if the address is 10.0.10.1, you still only get a range of 10.0.10.2 -> 10.0.10.254. But we also leave some addresses available above the host address for static stuff, like we did before. This is done on a sliding scale from 0 to 8 addresses, where about 1/10th the number of available addresses are reserved. https://bugzilla.gnome.org/show_bug.cgi?id=675973
2012-10-12 15:25:23 -05:00
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
g_return_val_if_fail (self, NULL);
g_return_val_if_fail (connection, NULL);
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
s_ip4 = nm_connection_get_setting_ip4_config (connection);
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
if (s_ip4 && nm_setting_ip_config_get_num_addresses (s_ip4)) {
core: allow custom IP address ranges for Shared connections (bgo #675973) Given an IPv4 address and prefix for a shared config, figure out the DHCP address range automatically. To keep things simple we allow a max of 252 addresses (not including network address, broadcast address, and the hotspot) no matter what prefix you use, so if the address is 10.0.10.1, you still only get a range of 10.0.10.2 -> 10.0.10.254. But we also leave some addresses available above the host address for static stuff, like we did before. This is done on a sliding scale from 0 to 8 addresses, where about 1/10th the number of available addresses are reserved. https://bugzilla.gnome.org/show_bug.cgi?id=675973
2012-10-12 15:25:23 -05:00
/* Use the first user-supplied address */
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
NMIPAddress *user = nm_setting_ip_config_get_address (s_ip4, 0);
platform: properly handle IPv4 peer-addresses The peer-address (IFA_ADDRESS) can also be all-zero (0.0.0.0). That is distinct from an usual address without explicit peer-address, which implicitly has the same peer and local address. Previously, we treated an all-zero peer_address as having peer and local address equal. This is especially grave, because the peer is part of the primary key for an IPv4 address. So we not only get a property of the address wrong, but we wrongly consider two different addresses as one and the same. To properly handle these addresses, we always must explicitly set the peer.
2015-10-21 23:17:11 +02:00
in_addr_t a;
core: allow custom IP address ranges for Shared connections (bgo #675973) Given an IPv4 address and prefix for a shared config, figure out the DHCP address range automatically. To keep things simple we allow a max of 252 addresses (not including network address, broadcast address, and the hotspot) no matter what prefix you use, so if the address is 10.0.10.1, you still only get a range of 10.0.10.2 -> 10.0.10.254. But we also leave some addresses available above the host address for static stuff, like we did before. This is done on a sliding scale from 0 to 8 addresses, where about 1/10th the number of available addresses are reserved. https://bugzilla.gnome.org/show_bug.cgi?id=675973
2012-10-12 15:25:23 -05:00
platform: properly handle IPv4 peer-addresses The peer-address (IFA_ADDRESS) can also be all-zero (0.0.0.0). That is distinct from an usual address without explicit peer-address, which implicitly has the same peer and local address. Previously, we treated an all-zero peer_address as having peer and local address equal. This is especially grave, because the peer is part of the primary key for an IPv4 address. So we not only get a property of the address wrong, but we wrongly consider two different addresses as one and the same. To properly handle these addresses, we always must explicitly set the peer.
2015-10-21 23:17:11 +02:00
nm_ip_address_get_address_binary (user, &a);
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
nm_platform_ip4_address_set_addr (&address, a, nm_ip_address_get_prefix (user));
core: allow custom IP address ranges for Shared connections (bgo #675973) Given an IPv4 address and prefix for a shared config, figure out the DHCP address range automatically. To keep things simple we allow a max of 252 addresses (not including network address, broadcast address, and the hotspot) no matter what prefix you use, so if the address is 10.0.10.1, you still only get a range of 10.0.10.2 -> 10.0.10.254. But we also leave some addresses available above the host address for static stuff, like we did before. This is done on a sliding scale from 0 to 8 addresses, where about 1/10th the number of available addresses are reserved. https://bugzilla.gnome.org/show_bug.cgi?id=675973
2012-10-12 15:25:23 -05:00
} else {
/* Find an unused address in the 10.42.x.x range */
guint32 start = (guint32) ntohl (0x0a2a0001); /* 10.42.0.1 */
guint32 count = 0;
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
if (G_UNLIKELY (!shared_ips))
shared_ips = g_hash_table_new (g_direct_hash, g_direct_equal);
else {
while (g_hash_table_lookup (shared_ips, GUINT_TO_POINTER (start + count))) {
count += ntohl (0x100);
if (count > ntohl (0xFE00)) {
_LOGE (LOGD_SHARING, "ran out of shared IP addresses!");
return FALSE;
}
core: allow custom IP address ranges for Shared connections (bgo #675973) Given an IPv4 address and prefix for a shared config, figure out the DHCP address range automatically. To keep things simple we allow a max of 252 addresses (not including network address, broadcast address, and the hotspot) no matter what prefix you use, so if the address is 10.0.10.1, you still only get a range of 10.0.10.2 -> 10.0.10.254. But we also leave some addresses available above the host address for static stuff, like we did before. This is done on a sliding scale from 0 to 8 addresses, where about 1/10th the number of available addresses are reserved. https://bugzilla.gnome.org/show_bug.cgi?id=675973
2012-10-12 15:25:23 -05:00
}
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
}
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
nm_platform_ip4_address_set_addr (&address, start + count, 24);
g_hash_table_add (shared_ips, GUINT_TO_POINTER (address.address));
is_generated = TRUE;
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
}
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
config = _ip4_config_new (self);
core: switch nm-ip4-config's NMIP[46]Address to NMPlatformIP[46]Address
2013-06-29 13:33:36 +02:00
nm_ip4_config_add_address (config, &address);
device: cleanup generating shared-IP in shared4_new_config() Changes: - merge reserve_shared_ip() into shared4_new_config(). shared4_new_config() needs to register release_shared_ip(). However, it wrongly would always register release_shared_ip(), even for user-supplied addresses. To fix that, we would need yet another argument to reserve_shared_ip() and coupling it even more with shared4_new_config(). At that point, it's cleaner to just merge the two functions. - only create the shared_ips hash when needed, and delete it when it's empty. The idea is, that NetworkManager possibly runs for a long time, and most of the time no shared connection is active. Just clean up the empty hash while we don't need it.
2017-05-28 11:28:23 +02:00
if (is_generated) {
/* Remove the address lock when the object gets disposed */
g_object_set_qdata_full (G_OBJECT (config), NM_CACHED_QUARK ("shared-ip"),
GUINT_TO_POINTER (address.address),
shared_ip_release);
}
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
return config;
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: move some code around No functional changes, but prepare for splitting DHCPv4 and DHCPv6 code apart.
2011-10-07 11:50:37 -05:00
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
static gboolean
connection_ip4_method_requires_carrier (NMConnection *connection,
gboolean *out_ip4_enabled)
{
const char *method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP4_CONFIG);
static const char *ip4_carrier_methods[] = {
NM_SETTING_IP4_CONFIG_METHOD_AUTO,
NM_SETTING_IP4_CONFIG_METHOD_LINK_LOCAL,
NULL
};
if (out_ip4_enabled)
*out_ip4_enabled = !!strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_DISABLED);
all: replace _nm_utils_string_in_list() with g_strv_contains()
2016-06-17 11:40:50 +02:00
return g_strv_contains (ip4_carrier_methods, method);
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
}
static gboolean
connection_ip6_method_requires_carrier (NMConnection *connection,
gboolean *out_ip6_enabled)
{
const char *method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG);
static const char *ip6_carrier_methods[] = {
NM_SETTING_IP6_CONFIG_METHOD_AUTO,
NM_SETTING_IP6_CONFIG_METHOD_DHCP,
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
NM_SETTING_IP6_CONFIG_METHOD_SHARED,
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
NM_SETTING_IP6_CONFIG_METHOD_LINK_LOCAL,
NULL
};
if (out_ip6_enabled)
*out_ip6_enabled = !!strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_IGNORE);
all: replace _nm_utils_string_in_list() with g_strv_contains()
2016-06-17 11:40:50 +02:00
return g_strv_contains (ip6_carrier_methods, method);
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
}
static gboolean
connection_requires_carrier (NMConnection *connection)
{
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
NMSettingIPConfig *s_ip4, *s_ip6;
device: don't wait for a carrier before enslaving devices The OpenVSwitch interfaces come into existence by their enslavement to a port. They can also bear an IP4 or IP6 configuration -- waiting on a carrier would deadlock the acitvation.
2017-10-26 19:56:52 +02:00
NMSettingConnection *s_con;
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
gboolean ip4_carrier_wanted, ip6_carrier_wanted;
gboolean ip4_used = FALSE, ip6_used = FALSE;
device: don't wait for a carrier before enslaving devices The OpenVSwitch interfaces come into existence by their enslavement to a port. They can also bear an IP4 or IP6 configuration -- waiting on a carrier would deadlock the acitvation.
2017-10-26 19:56:52 +02:00
/* We can progress to IP_CONFIG now, so that we're enslaved.
* That may actually cause carrier to go up and thus continue acivation. */
s_con = nm_connection_get_setting_connection (connection);
if (nm_setting_connection_get_master (s_con))
return FALSE;
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
ip4_carrier_wanted = connection_ip4_method_requires_carrier (connection, &ip4_used);
if (ip4_carrier_wanted) {
/* If IPv4 wants a carrier and cannot fail, the whole connection
* requires a carrier regardless of the IPv6 method.
*/
s_ip4 = nm_connection_get_setting_ip4_config (connection);
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
if (s_ip4 && !nm_setting_ip_config_get_may_fail (s_ip4))
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
return TRUE;
}
ip6_carrier_wanted = connection_ip6_method_requires_carrier (connection, &ip6_used);
if (ip6_carrier_wanted) {
/* If IPv6 wants a carrier and cannot fail, the whole connection
* requires a carrier regardless of the IPv4 method.
*/
s_ip6 = nm_connection_get_setting_ip6_config (connection);
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
if (s_ip6 && !nm_setting_ip_config_get_may_fail (s_ip6))
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
return TRUE;
}
all: fix typos in documentation and comments https://bugzilla.gnome.org/show_bug.cgi?id=780199 [thaller@redhat.com: reworded commit message]
2017-03-17 15:57:50 +02:00
/* If an IP version wants a carrier and the other IP version isn't
trivial: move connection_requires_carrer() up No code change, only move above a future user.
2014-10-13 17:29:53 -05:00
* used, the connection requires carrier since it will just fail without one.
*/
if (ip4_carrier_wanted && !ip6_used)
return TRUE;
if (ip6_carrier_wanted && !ip4_used)
return TRUE;
/* If both want a carrier, the whole connection wants a carrier */
return ip4_carrier_wanted && ip6_carrier_wanted;
}
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
static gboolean
device: simplify check for ready slaves
2017-05-14 09:52:18 +02:00
have_any_ready_slaves (NMDevice *self)
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
{
device: simplify check for ready slaves
2017-05-14 09:52:18 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
SlaveInfo *info;
CList *iter;
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
/* Any enslaved slave is "ready" in the generic case as it's
* at least >= NM_DEVCIE_STATE_IP_CONFIG and has had Layer 2
* properties set up.
*/
device: simplify check for ready slaves
2017-05-14 09:52:18 +02:00
c_list_for_each (iter, &priv->slaves) {
info = c_list_entry (iter, SlaveInfo, lst_slave);
if (NM_DEVICE_GET_PRIVATE (info->slave)->is_enslaved)
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
return TRUE;
}
return FALSE;
}
static gboolean
ip4_requires_slaves (NMConnection *connection)
{
core: don't have IP4 and IP6 configs on slaves Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
2013-10-14 10:38:56 -04:00
const char *method;
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
core: don't have IP4 and IP6 configs on slaves Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
2013-10-14 10:38:56 -04:00
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP4_CONFIG);
settings: make connections always have s_ip4 and s_ip6 Make sure that all connections returned from NMSettings or created via AddAndActivateConnection have an NMSettingIP4Config and an NMSettingIP6Config, with non-NULL methods, and get rid of now-unnecessary checks for those. Also move the slaves-can't-have-IP-config checks into the platform-independent code as well. This also gets rid of spurious "ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a slave ifcfg file. Partly based on a patch from Pavel. https://bugzilla.gnome.org/show_bug.cgi?id=708875
2013-09-26 17:34:23 -04:00
return strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_AUTO) == 0;
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
}
2006-1-3 Dan Williams <dcbw@redhat.com> * src/nm-device-802-11-wireless.c src/nm-device.[ch] - Add hooks to subclasses for stage3_ip_config_start and stage4_ip_config_timeout * src/nm-device-802-3-ethernet.c - (real_get_generic_capabilities): make devices NM-supported by default git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1251 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:47:38 +00:00
static NMActStageReturn
core: remove "real_" prefix from method implementation names The idea was copied from gtk, but it's only used there in cases where the method's wrapper function and default implementation would otherwise have the same name, which never happens in NM because our method implementations aren't prefixed with the type name, so it's just noise here.
2012-09-27 12:12:15 -04:00
act_stage3_ip4_config_start (NMDevice *self,
NMIP4Config **out_config,
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NMDeviceStateReason *out_failure_reason)
2007-06-06 Tambet Ingo <tambet@ximian.com> * libnm-util/nm-setting.c: Get rid of dump virtual functions, that can happen automagically. Implement NMSettingIP4Config. Finish NMSettingWired by adding all known members. (setting_wired_verify): Implement. Finish NMSettingWireless by adding all known members. (setting_wireless_verify): Implement. * libnm-util/nm-connection.c: Register "ipv4" setting. (nm_connection_dump): Implement. Instead of requiring every NMSetting to implement dump function, we can introspect the GHashTable which is used for sending connections over dbus. * src/nm-device-802-11-wireless.c (nm_device_802_11_wireless_set_activation_ap): Take GByteArray for essid, it's really not a string. * src/nm-device.c (real_act_stage3_ip_config_start): Get information from NMSettings. Start DHCP request if setting is not passed or if it states that DHCP should be used. (real_act_stage4_get_ip4_config): If settings are provided, use them, even if it means overriding the values we got from DHCP. (real_activation_cancel_handler): Cancel DHCP transaction only if it has started, doh. (nm_device_deactivate_quickly): Ditto. * src/nm-device-interface.c (impl_device_activate): Dump the connection structure for debugging. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2577 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-06 13:33:51 +00:00
{
core: don't even bother running IPv4 or IPv6 when they are disabled
2010-04-23 12:56:33 -07:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
dhcp: (dhclient) use per-connection leasefiles and don't delete on deactivate So that leases are actually useful...
2009-05-03 00:51:09 -04:00
NMConnection *connection;
core: better failure handling when starting IP configuration First, log when there's an unhandled IP config method, and second, assume failure in IPv4 configs. IPv6 already did.
2011-12-06 17:00:40 -06:00
NMActStageReturn ret = NM_ACT_STAGE_RETURN_FAILURE;
core: don't have IP4 and IP6 configs on slaves Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
2013-10-14 10:38:56 -04:00
const char *method;
2008-07-09 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-avahi-autoipd-action.c callouts/nm-avahi-autoipd.conf - avahi-autoipd callout to send options back to NM * src/autoip.c src/autoip.h - remove * src/nm-device.c src/nm-device-private.h src/nm-manager.c - Use avahi-autoipd for IPv4LL functionality rather than really crappy old custom stuff git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3816 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-09 14:05:49 +00:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
g_return_val_if_fail (connection, NM_ACT_STAGE_RETURN_FAILURE);
wired: ignore carrier state for manual/static bridge and bond connections NM is supposed to ignore carrier and slave states for manual/static connections when bringing up bonds and bridges, on the theory that since static configuration does not require connectivity, there's no need to wait for that connectivity to happen. This wasn't happening during the IP configuration phase, but was happening before getting to the IP config phase where the device waits for slaves before starting IP configuration if the method requires connectivity.
2013-06-07 15:11:23 -05:00
core: loosen master device carrier check before IP configuration Previously a master device would wait for a carrier before starting IP configuration only for 'manual' connections, but that's not quite broad enough. We also want to allow SHARED methods to proceed immediately since they are also effectively static/manual configuration. Use the newly split out methods for checking whether a connection requires a carrier or not to allow the SHARED method to proceed for master devices without a carrier. For example, this allows bridge configurations with tun/tap ports to set up SHARED addressing before the tun/tap gets a carrier which only happens when something opens the other side of the tun/tap (like the VM or container).
2014-10-14 11:41:36 -05:00
if ( connection_ip4_method_requires_carrier (connection, NULL)
device: transform NM_DEVICE_IS_MASTER gobject property to field in NMDeviceClass We don't need this flexibility of having a full fledged GObject property for is-master. The property value only depends on the device's class.
2017-06-01 23:08:30 +02:00
&& nm_device_is_master (self)
core: postpone non-static master IP configuration until carrier This got broken at some point. The intent of ignore-carrier was always to ignore the carrier for IP configuration for static/manual connections, but never for DHCP/SLAAC where a link is actually required. Thus when checking whether to postpone IP configuration for a master interface that's using DHCP/SLAAC, don't allow ignore-carrier to factor into the decision.
2014-02-25 18:00:34 -06:00
&& !priv->carrier) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_IP4 | LOGD_DEVICE,
"IPv4 config waiting until carrier is on");
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
return NM_ACT_STAGE_RETURN_IP_WAIT;
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
}
device: transform NM_DEVICE_IS_MASTER gobject property to field in NMDeviceClass We don't need this flexibility of having a full fledged GObject property for is-master. The property value only depends on the device's class.
2017-06-01 23:08:30 +02:00
if (nm_device_is_master (self) && ip4_requires_slaves (connection)) {
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
/* If the master has no ready slaves, and depends on slaves for
* a successful IPv4 attempt, then postpone IPv4 addressing.
*/
device: simplify check for ready slaves
2017-05-14 09:52:18 +02:00
if (!have_any_ready_slaves (self)) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_DEVICE | LOGD_IP4,
"IPv4 config waiting until slaves are ready");
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
return NM_ACT_STAGE_RETURN_IP_WAIT;
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
}
}
core: loosen master device carrier check before IP configuration Previously a master device would wait for a carrier before starting IP configuration only for 'manual' connections, but that's not quite broad enough. We also want to allow SHARED methods to proceed immediately since they are also effectively static/manual configuration. Use the newly split out methods for checking whether a connection requires a carrier or not to allow the SHARED method to proceed for master devices without a carrier. For example, this allows bridge configurations with tun/tap ports to set up SHARED addressing before the tun/tap gets a carrier which only happens when something opens the other side of the tun/tap (like the VM or container).
2014-10-14 11:41:36 -05:00
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP4_CONFIG);
device: retry DHCPv4 when a lease expires Make DHCPv4 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:00:47 +02:00
priv->dhcp4.num_tries_left = DHCP_NUM_TRIES_MAX;
core: loosen master device carrier check before IP configuration Previously a master device would wait for a carrier before starting IP configuration only for 'manual' connections, but that's not quite broad enough. We also want to allow SHARED methods to proceed immediately since they are also effectively static/manual configuration. Use the newly split out methods for checking whether a connection requires a carrier or not to allow the SHARED method to proceed for master devices without a carrier. For example, this allows bridge configurations with tun/tap ports to set up SHARED addressing before the tun/tap gets a carrier which only happens when something opens the other side of the tun/tap (like the VM or container).
2014-10-14 11:41:36 -05:00
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
/* Start IPv4 addressing based on the method requested */
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
if (strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_AUTO) == 0) {
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
ret = dhcp4_start (self);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
if (ret == NM_ACT_STAGE_RETURN_FAILURE)
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_DHCP_START_FAILED);
} else if (strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_LINK_LOCAL) == 0) {
ret = ipv4ll_start (self);
if (ret == NM_ACT_STAGE_RETURN_FAILURE)
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_AUTOIP_START_FAILED);
} else if (strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_MANUAL) == 0) {
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
NMIP4Config **configs, *config;
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
config = _ip4_config_new (self);
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
nm_ip4_config_merge_setting (config,
nm_connection_get_setting_ip4_config (connection),
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
nm_device_get_route_table (self, AF_INET, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET));
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
configs = g_new0 (NMIP4Config *, 2);
configs[0] = config;
ipv4_dad_start (self, configs, ipv4_manual_method_apply);
ret = NM_ACT_STAGE_RETURN_POSTPONE;
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
} else if (strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_SHARED) == 0) {
device: add new result NM_ACT_STAGE_RETURN_IP_DONE for ip config activation This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set the IP state without commiting an NMIP[46]Config instance.
2016-08-31 20:01:12 +02:00
if (out_config) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
*out_config = shared4_new_config (self, connection);
device: add new result NM_ACT_STAGE_RETURN_IP_DONE for ip config activation This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set the IP state without commiting an NMIP[46]Config instance.
2016-08-31 20:01:12 +02:00
if (*out_config) {
priv->dnsmasq_manager = nm_dnsmasq_manager_new (nm_device_get_ip_iface (self));
ret = NM_ACT_STAGE_RETURN_SUCCESS;
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
} else {
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE);
device: add new result NM_ACT_STAGE_RETURN_IP_DONE for ip config activation This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set the IP state without commiting an NMIP[46]Config instance.
2016-08-31 20:01:12 +02:00
ret = NM_ACT_STAGE_RETURN_FAILURE;
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
}
core: better failure handling when starting IP configuration First, log when there's an unhandled IP config method, and second, assume failure in IPv4 configs. IPv6 already did.
2011-12-06 17:00:40 -06:00
} else
device: add new result NM_ACT_STAGE_RETURN_IP_DONE for ip config activation This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set the IP state without commiting an NMIP[46]Config instance.
2016-08-31 20:01:12 +02:00
g_return_val_if_reached (NM_ACT_STAGE_RETURN_FAILURE);
device: don't call _commit_mtu() when ipv4.method=disabled After commit 553717bb1c9e ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"), we commit an empty IPv4 configuration when IPv4 is disabled. This means that it's not necessary anymore to call _commit_mtu() because the MTU will be set in ip4_config_merge_and_apply(). (cherry picked from commit 714b18dcf77d029a53c3b371c2f05bd5c7cc3bff)
2017-01-20 16:12:21 +01:00
} else if (strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_DISABLED) == 0)
device: don't set ip4_state=IP_FAIL for ipv4.method=disabled ... and don't set ip6_state=IP_FAIL for ipv6.method=ignore. The disabled state is like having an empty NMIP4Config object. It should not result in %IP_FAIL state. Instead, we just want to proceed and commit an empty NMIP4Config instance. This was introduced by commit 0652d9c5961e4636eab87647af890aaf8c3e3269, which I think was wrong. Likewise, for ipv6.method=ignore we also don't want to mark the IP state as failed. Instead, we want to proceed and set IP_DONE right away -- without commiting anything, which is a difference to the IPv4 case. This is especially important, because an ip4_state/ip6_state of IP_FAIL causes nm_device_can_assume_active_connection() to return FALSE, which means we unmanage devices at shutdown. Ony might say that it doesn't matter so much for a device without IP configuration, but imagine a bond with VLANs on top that only has Layer 2 configuration. This will bring down the entire stack. With this change, devices with IP methods disabled/ignore stay up on exit of NetworkManager (rh#1371126). Of course, that means on restart software devices stay unamanged due to external-down (because since commit e1edcda, devices without IP address are also external-down). So, this really just fixes one scenario, breaking another one. This should be fixed with bgo#746440 by not assuming connections. https://bugzilla.redhat.com/show_bug.cgi?id=1371126
2016-08-29 15:37:55 +02:00
ret = NM_ACT_STAGE_RETURN_SUCCESS;
device: don't call _commit_mtu() when ipv4.method=disabled After commit 553717bb1c9e ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"), we commit an empty IPv4 configuration when IPv4 is disabled. This means that it's not necessary anymore to call _commit_mtu() because the MTU will be set in ip4_config_merge_and_apply(). (cherry picked from commit 714b18dcf77d029a53c3b371c2f05bd5c7cc3bff)
2017-01-20 16:12:21 +01:00
else
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_IP4, "unhandled IPv4 config method '%s'; will fail", method);
2007-02-05 Tambet Ingo <tambet@ximian.com> * src/NetworkManagerMain.h: Remove all references to DHCP manager. * src/NetworkManager.c: Don't initialize the DHCP manager, it's a singleton now. * src/nm-device.c: Use the new DHCP manager API. * src/nm-activation-request.c: * src/nm-activation-request.h: - Remove all dhcp related properties and methods. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2284 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 09:50:11 +00:00
2006-1-3 Dan Williams <dcbw@redhat.com> * src/nm-device-802-11-wireless.c src/nm-device.[ch] - Add hooks to subclasses for stage3_ip_config_start and stage4_ip_config_timeout * src/nm-device-802-3-ethernet.c - (real_get_generic_capabilities): make devices NM-supported by default git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1251 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:47:38 +00:00
return ret;
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
/* DHCPv6 stuff */
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
dhcp6_cleanup (NMDevice *self, CleanupType cleanup_type, gboolean release)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
priv->dhcp6.mode = NM_NDISC_DHCP_LEVEL_NONE;
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
g_clear_object (&priv->dhcp6.ip6_config);
g_clear_pointer (&priv->dhcp6.event_id, g_free);
nm_clear_g_source (&priv->dhcp6.restart_id);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
if (priv->dhcp6.client) {
nm_clear_g_signal_handler (priv->dhcp6.client, &priv->dhcp6.state_sigid);
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
nm_clear_g_signal_handler (priv->dhcp6.client, &priv->dhcp6.prefix_sigid);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
if ( cleanup_type == CLEANUP_TYPE_DECONFIGURE
|| cleanup_type == CLEANUP_TYPE_REMOVED)
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
nm_dhcp_client_stop (priv->dhcp6.client, release);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
g_clear_object (&priv->dhcp6.client);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: fix dhcp4_cleanup() to clear dhcp4_client first (avoids assert accessing NM_DEVICE_DHCP4_CONFIG) dhcp4_cleanup() should first clear @dhcp4_client variables before clearing @dhcp4_config. Otherwise the following assert fails [1] and the DBUS property NM_DEVICE_DHCP4_CONFIG is set to %NULL. Analog to dhcp6_cleanup(), dhcp6_client, and NM_DEVICE_DHCP6_CONFIG. [1] backtrace: #0 0x0000003370c504e9 in g_logv (log_domain=0x4c148c "unrecognized-specs-changed", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff4710ed60) at gmessages.c:989 #1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x3370cbc89a "%s: assertion '%s' failed") at gmessages.c:1025 #2 0x0000003370c50679 in g_return_if_fail_warning (log_domain=log_domain@entry=0x4c144c "NetworkManager", pretty_function=pretty_function@entry=0x4c6140 <__PRETTY_FUNCTION__.15969> "nm_dhcp4_config_get_dbus_path", expression=expression@entry=0x4c60d9 "NM_IS_DHCP4_CONFIG (self)") at gmessages.c:1034 #3 0x000000000046b1d4 in nm_dhcp4_config_get_dbus_path (self=0x0) at nm-dhcp4-config.c:115 #4 0x0000000000434791 in get_property (object=0x9d2320, prop_id=13, value=0x9618a0, pspec=0x9bbc20) at devices/nm-device.c:7539 #5 0x0000003371c18e73 in object_get_property (value=0x9618a0, pspec=<optimized out>, object=0x9d2320) at gobject.c:1303 #6 g_object_get_property (object=0x9d2320, property_name=<optimized out>, value=0x9618a0) at gobject.c:2402 #7 0x000000000048482c in idle_id_reset (data=<optimized out>) at nm-properties-changed-signal.c:123 #8 0x0000003371c13055 in g_cclosure_marshal_VOID__PARAM (closure=0x9618a0, return_value=0xffffffff, n_param_values=0, param_values=0x7fff4710f130, invocation_hint=0x0, marshal_data=0x4b5201) at gmarshal.c:1037 #9 0x0000003371c10298 in g_closure_invoke (closure=0x2, closure@entry=0x919d00, return_value=return_value@entry=0x0, n_param_values=1192292656, param_values=0x9d2320, param_values@entry=0x7fff4710f130, invocation_hint=invocation_hint@entry=0x7fff4710f0d0) at gclosure.c:777 #10 0x0000003371c21b87 in signal_emit_unlocked_R (node=node@entry=0x919d90, detail=detail@entry=667, instance=instance@entry=0x9d2320, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff4710f130) at gsignal.c:3516 #11 0x0000003371c2a0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff4710f2c0) at gsignal.c:3330 #12 0x0000003371c2a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386 #13 0x0000003371c14945 in g_object_dispatch_properties_changed (object=0x9d2320, n_pspecs=4294967295, pspecs=0x0) at gobject.c:1047 #14 0x0000003371c17019 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0x9d2320) at gobject.c:1141 #15 g_object_notify (object=0x9d2320, property_name=property_name@entry=0x4c400f "dhcp4-config") at gobject.c:1183 #16 0x0000000000434332 in dhcp4_cleanup (self=self@entry=0x9d2320, stop=stop@entry=1, release=release@entry=0) at devices/nm-device.c:2581 #17 0x0000000000434cab in _cleanup_generic_pre (self=self@entry=0x9d2320, deconfigure=deconfigure@entry=1) at devices/nm-device.c:6448 #18 0x0000000000436db1 in nm_device_cleanup (self=self@entry=0x9d2320, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6524 #19 0x0000000000437358 in _set_state_full (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6641 #20 0x000000000043797c in nm_device_state_changed (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823 #21 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0x9d2320, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983 #22 0x000000000043a193 in nm_device_set_unmanaged_quitting (device=0x9d2320) at devices/nm-device.c:5998 #23 0x00000000004799f9 in remove_device (manager=0x9b2150, device=0x9d2320, quitting=1) at nm-manager.c:775 #24 0x000000000047bf47 in dispose (object=0x9b2150) at nm-manager.c:4935 #25 0x0000003371c14ee8 in g_object_unref (_object=0x9b2150) at gobject.c:3160 #26 0x0000000000429f43 in main (argc=1, argv=0x7fff4710f9a8) at main.c:681 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-23 10:32:32 +02:00
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_remove_pending_action (self, NM_PENDING_ACTION_DHCP6, FALSE);
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
if (priv->dhcp6.config) {
nm_exported_object_clear_and_unexport (&priv->dhcp6.config);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_DHCP6_CONFIG);
core: fix dhcp4_cleanup() to clear dhcp4_client first (avoids assert accessing NM_DEVICE_DHCP4_CONFIG) dhcp4_cleanup() should first clear @dhcp4_client variables before clearing @dhcp4_config. Otherwise the following assert fails [1] and the DBUS property NM_DEVICE_DHCP4_CONFIG is set to %NULL. Analog to dhcp6_cleanup(), dhcp6_client, and NM_DEVICE_DHCP6_CONFIG. [1] backtrace: #0 0x0000003370c504e9 in g_logv (log_domain=0x4c148c "unrecognized-specs-changed", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff4710ed60) at gmessages.c:989 #1 0x0000003370c5063f in g_log (log_domain=log_domain@entry=0x4c144c "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x3370cbc89a "%s: assertion '%s' failed") at gmessages.c:1025 #2 0x0000003370c50679 in g_return_if_fail_warning (log_domain=log_domain@entry=0x4c144c "NetworkManager", pretty_function=pretty_function@entry=0x4c6140 <__PRETTY_FUNCTION__.15969> "nm_dhcp4_config_get_dbus_path", expression=expression@entry=0x4c60d9 "NM_IS_DHCP4_CONFIG (self)") at gmessages.c:1034 #3 0x000000000046b1d4 in nm_dhcp4_config_get_dbus_path (self=0x0) at nm-dhcp4-config.c:115 #4 0x0000000000434791 in get_property (object=0x9d2320, prop_id=13, value=0x9618a0, pspec=0x9bbc20) at devices/nm-device.c:7539 #5 0x0000003371c18e73 in object_get_property (value=0x9618a0, pspec=<optimized out>, object=0x9d2320) at gobject.c:1303 #6 g_object_get_property (object=0x9d2320, property_name=<optimized out>, value=0x9618a0) at gobject.c:2402 #7 0x000000000048482c in idle_id_reset (data=<optimized out>) at nm-properties-changed-signal.c:123 #8 0x0000003371c13055 in g_cclosure_marshal_VOID__PARAM (closure=0x9618a0, return_value=0xffffffff, n_param_values=0, param_values=0x7fff4710f130, invocation_hint=0x0, marshal_data=0x4b5201) at gmarshal.c:1037 #9 0x0000003371c10298 in g_closure_invoke (closure=0x2, closure@entry=0x919d00, return_value=return_value@entry=0x0, n_param_values=1192292656, param_values=0x9d2320, param_values@entry=0x7fff4710f130, invocation_hint=invocation_hint@entry=0x7fff4710f0d0) at gclosure.c:777 #10 0x0000003371c21b87 in signal_emit_unlocked_R (node=node@entry=0x919d90, detail=detail@entry=667, instance=instance@entry=0x9d2320, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff4710f130) at gsignal.c:3516 #11 0x0000003371c2a0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff4710f2c0) at gsignal.c:3330 #12 0x0000003371c2a3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386 #13 0x0000003371c14945 in g_object_dispatch_properties_changed (object=0x9d2320, n_pspecs=4294967295, pspecs=0x0) at gobject.c:1047 #14 0x0000003371c17019 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0x9d2320) at gobject.c:1141 #15 g_object_notify (object=0x9d2320, property_name=property_name@entry=0x4c400f "dhcp4-config") at gobject.c:1183 #16 0x0000000000434332 in dhcp4_cleanup (self=self@entry=0x9d2320, stop=stop@entry=1, release=release@entry=0) at devices/nm-device.c:2581 #17 0x0000000000434cab in _cleanup_generic_pre (self=self@entry=0x9d2320, deconfigure=deconfigure@entry=1) at devices/nm-device.c:6448 #18 0x0000000000436db1 in nm_device_cleanup (self=self@entry=0x9d2320, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6524 #19 0x0000000000437358 in _set_state_full (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED, quitting=quitting@entry=0) at devices/nm-device.c:6641 #20 0x000000000043797c in nm_device_state_changed (device=device@entry=0x9d2320, state=state@entry=NM_DEVICE_STATE_UNMANAGED, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6823 #21 0x0000000000439fe7 in nm_device_set_unmanaged (device=device@entry=0x9d2320, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:5983 #22 0x000000000043a193 in nm_device_set_unmanaged_quitting (device=0x9d2320) at devices/nm-device.c:5998 #23 0x00000000004799f9 in remove_device (manager=0x9b2150, device=0x9d2320, quitting=1) at nm-manager.c:775 #24 0x000000000047bf47 in dispose (object=0x9b2150) at nm-manager.c:4935 #25 0x0000003371c14ee8 in g_object_unref (_object=0x9b2150) at gobject.c:3160 #26 0x0000000000429f43 in main (argc=1, argv=0x7fff4710f9a8) at main.c:681 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-23 10:32:32 +02:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
static gboolean
ip6_config_merge_and_apply (NMDevice *self,
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
gboolean commit)
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
ip6: don't 'assume' IPv6 connections (bgo #676740) The bug report describes a testing scenario where device is down and no IPv4 or IPv6 addresses are set up. Then NetworkManager is started and it decides not to configure DHCPv6 address. This is caused by code copied from IPv4 that does not work here at all (and I wonder if it does in IPv4). In any case, when NetworkManager starts a DHCP client and recieves an IPv6 address (no addresses are configured at the time), it *must* send this new IPv6 address to the kernel. (dcbw) We should fix the connection takeover code for IPv6 but it's not a quick fix so in the mean time disable the buggy code and we'll fix IPv6 takeover cleanly soon.
2012-05-24 15:37:40 +02:00
gboolean success;
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
NMIP6Config *composite;
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
gboolean ignore_auto_routes = FALSE;
gboolean ignore_auto_dns = FALSE;
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
gboolean ignore_default_routes = FALSE;
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
const char *token = NULL;
device: minor cleanup replacing g_slist_for_each() by iteration Iterating a list is so easy, it's easier to just do it by hand, then splitting the functionality accross multiple lines.
2017-05-26 22:46:57 +02:00
GSList *iter;
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
/* Apply ignore-auto-routes and ignore-auto-dns settings */
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
if (connection) {
NMSettingIPConfig *s_ip6 = nm_connection_get_setting_ip6_config (connection);
if (s_ip6) {
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
NMSettingIP6Config *ip6 = NM_SETTING_IP6_CONFIG (s_ip6);
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
ignore_auto_routes = nm_setting_ip_config_get_ignore_auto_routes (s_ip6);
ignore_auto_dns = nm_setting_ip_config_get_ignore_auto_dns (s_ip6);
device: don't configure automatic default-routes if an explicit gateway is set Since commit 5c299454b49b165f645c25fd3e083c0bb747ad91 we can configure multiple default-routes. That is especially useful with IPv6 to configure multiple routers. It will also be useful, once we allow configuring manual default-routes, like regular static routes. However the problem is, that the default-route for the manual gateway and the gateway from DHCP both get the same metric. So it's undefined which route is used. To avoid that problem, and to restore previous behavior, don't accept any default-routes if a gateway is set. Fixes: 5c299454b49b165f645c25fd3e083c0bb747ad91
2017-10-24 20:46:24 +02:00
/* if the connection has an explicit gateway, we also ignore
* the default routes from other sources. */
ignore_default_routes = nm_setting_ip_config_get_never_default (s_ip6)
|| nm_setting_ip_config_get_gateway (s_ip6);
device: take care of default route of DHCP generated-assumed connections In general we don't touch the externally set default route on devices that use a generated-assumed connection. When the IP method is AUTO (or DHCP), this means that we are not able to restore the default route after a temporary expiration of the lease which removes addresses/routes from the device. Change this, and let NM update the default route for generated-assumed devices using dynamic addressing. https://bugzilla.redhat.com/show_bug.cgi?id=1265239
2016-03-15 12:03:23 +01:00
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
if (nm_setting_ip6_config_get_addr_gen_mode (ip6) == NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64)
token = nm_setting_ip6_config_get_token (ip6);
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
}
}
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
composite = _ip6_config_new (self);
ip6-config: add nm_ip6_config_set_privacy()
2016-11-18 11:52:53 +01:00
nm_ip6_config_set_privacy (composite,
priv->ndisc ?
priv->ndisc_use_tempaddr :
NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN);
core: use default value for ipvx.dns-priority Fall back to system default value for ipvx.dns-priority when it's zero in the setting. For VPNs the default value is 50; for other connections is 100, but it depends also on the content of [connection*] sections in NetworkManager.conf.
2016-05-09 16:30:41 +02:00
init_ip6_config_dns_priority (self, composite);
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
device: update external configuration before commit If the platform signaled that the external configuration changed (and thus update_ipX_config() is scheduled) and we are doing a commit of the new configuration, update priv->ext_ipX_config. Without this, the commit will remove addresses added externally but not yet captured in the external configuration. https://bugzilla.redhat.com/show_bug.cgi?id=1449873
2017-05-12 12:00:20 +02:00
if (commit) {
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
if (priv->queued_ip6_config_id)
update_ext_ip_config (self, AF_INET6, FALSE, FALSE);
device: split ensure_ipx_config() into IPv4 and IPv6 (bgo #751430) Without that we can remove addresses from con-ip6-config due to external changes *before* it is applied and thus manual IPv6 addresses are not applied together with ipv6.method=auto. Testcase: $ nmcli con add type ether con-name AAA ifname eth0 autoconnect no $ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64 $ nmcli con up AAA Fixes:Beaker:NetworkManager_Test37_run_once_new_connection Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked https://bugzilla.gnome.org/show_bug.cgi?id=751430
2015-06-24 09:42:58 +00:00
ensure_con_ip6_config (self);
device: update external configuration before commit If the platform signaled that the external configuration changed (and thus update_ipX_config() is scheduled) and we are doing a commit of the new configuration, update priv->ext_ipX_config. Without this, the commit will remove addresses added externally but not yet captured in the external configuration. https://bugzilla.redhat.com/show_bug.cgi?id=1449873
2017-05-12 12:00:20 +02:00
}
core: use default value for ipvx.dns-priority Fall back to system default value for ipvx.dns-priority when it's zero in the setting. For VPNs the default value is 50; for other connections is 100, but it depends also on the content of [connection*] sections in NetworkManager.conf.
2016-05-09 16:30:41 +02:00
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (commit)
priv->default_route_metric_penalty_ip6_has = default_route_metric_penalty_detect (self);
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
/* Merge all the IP configs into the composite config */
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
if (priv->ac_ip6_config) {
nm_ip6_config_merge (composite, priv->ac_ip6_config,
(ignore_auto_routes ? NM_IP_CONFIG_MERGE_NO_ROUTES : 0)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
| (ignore_default_routes ? NM_IP_CONFIG_MERGE_NO_DEFAULT_ROUTES : 0)
| (ignore_auto_dns ? NM_IP_CONFIG_MERGE_NO_DNS : 0),
default_route_metric_penalty_get (self, AF_INET6));
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
}
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
if (priv->dhcp6.ip6_config) {
nm_ip6_config_merge (composite, priv->dhcp6.ip6_config,
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
(ignore_auto_routes ? NM_IP_CONFIG_MERGE_NO_ROUTES : 0)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
| (ignore_default_routes ? NM_IP_CONFIG_MERGE_NO_DEFAULT_ROUTES : 0)
| (ignore_auto_dns ? NM_IP_CONFIG_MERGE_NO_DNS : 0),
default_route_metric_penalty_get (self, AF_INET6));
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
}
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
device: minor cleanup replacing g_slist_for_each() by iteration Iterating a list is so easy, it's easier to just do it by hand, then splitting the functionality accross multiple lines.
2017-05-26 22:46:57 +02:00
for (iter = priv->vpn6_configs; iter; iter = iter->next)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip6_config_merge (composite, iter->data, NM_IP_CONFIG_MERGE_DEFAULT, 0);
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
core: handle externally added IPv6 adresses and routes on IP change 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.
2013-08-15 12:55:56 -05:00
if (priv->ext_ip6_config)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip6_config_merge (composite, priv->ext_ip6_config, NM_IP_CONFIG_MERGE_DEFAULT, 0);
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
/* Merge WWAN config *last* to ensure modem-given settings overwrite
* any external stuff set by pppd or other scripts.
*/
device: only 'ignore-auto-routes' and 'ignore-auto-dns' for certain settings During merge_and_apply(), we merge several NMIPxConfig into a new @composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to prevent certain routes/dns-settings to be merged. But it is wrong to reject settings from all partial configs. For example, especially ext_ipx_config and vpn_ipx_config contain routes that we still must merge and preserve. This was recently changed by 79630c11e502c3b0b958abc0b1b5d777a3db2a98 and previously by ab6548c62134518ba2871306397e7fb9c84260ca. But it was wrong for a long time already. Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and dns-options. https://bugzilla.gnome.org/show_bug.cgi?id=752546 Fixes: 79630c11e502c3b0b958abc0b1b5d777a3db2a98
2015-08-05 10:15:20 +02:00
if (priv->wwan_ip6_config) {
nm_ip6_config_merge (composite, priv->wwan_ip6_config,
(ignore_auto_routes ? NM_IP_CONFIG_MERGE_NO_ROUTES : 0)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
| (ignore_default_routes ? NM_IP_CONFIG_MERGE_NO_DEFAULT_ROUTES : 0)
| (ignore_auto_dns ? NM_IP_CONFIG_MERGE_NO_DNS : 0),
default_route_metric_penalty_get (self, AF_INET6));
device: fix handling of ignore-auto-dns and ignore-auto-routes Since commit ab6548c62134 ("device: better accept external IP changes"), ipX_config_merge_and_apply() applies the configuration static settings to an intermediate, initially empty configuration (priv->con_ipX_config) instead of the composite configuration, and thus the handling of ignore-auto-routes and ignore-auto-dns options done in nm_ipX_config_merge_setting() has no effect. Fix this by clearing the routes and the DNS information when needed before merging static settings to the composite configuration. Fixes: ab6548c62134518ba2871306397e7fb9c84260ca
2015-06-25 11:24:32 +02:00
}
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
if (priv->rt6_temporary_not_available) {
const NMPObject *o;
GHashTableIter hiter;
g_hash_table_iter_init (&hiter, priv->rt6_temporary_not_available);
while (g_hash_table_iter_next (&hiter, (gpointer *) &o, NULL)) {
nm_ip6_config_add_route (composite,
NMP_OBJECT_CAST_IP6_ROUTE (o),
NULL);
}
}
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
/* Merge user overrides into the composite config. For assumed connections,
* con_ip6_config is empty. */
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (priv->con_ip6_config) {
nm_ip6_config_merge (composite, priv->con_ip6_config, NM_IP_CONFIG_MERGE_DEFAULT,
default_route_metric_penalty_get (self, AF_INET6));
core: fix tracking default-route during device's merge and apply If we don't commit the IP config, we must merge the currently tracked default route. Otherwise, on every non-commit call of ip4_config_merge_and_apply(), the default-route gets lost. Fixes: 77ec302714795f905301d500b9aab6c88001f32e
2017-09-18 09:22:35 +02:00
}
core: fix handling IPv6 device-route and use correct route metric Before commit 6698bf58bb53fb07838c52ca67293dd5352ec31c, we would rely on kernel to add the device-route for manual IPv6 routes. We broke that and now kernel would still add the device-route, however nm_platform_ip_route_sync() would delete it immediately after. That is because previously nm_platform_ip_route_sync() would ignore routes with rtm_protocol RTPRO_KERNEL. Now, it will sync and delete those too. Fix that by adding the device-route like we do it for IPv4. This also fixes an actual issue where the automatically added route always had route-metric 256. Instead, we now use the metric from ipv6.route-metric setting. Fixes: 6698bf58bb53fb07838c52ca67293dd5352ec31c
2017-09-19 09:40:13 +02:00
if (commit) {
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip6_config_add_dependent_routes (composite,
nm_device_get_route_table (self, AF_INET6, TRUE),
nm_device_get_route_metric (self, AF_INET6));
core: fix handling IPv6 device-route and use correct route metric Before commit 6698bf58bb53fb07838c52ca67293dd5352ec31c, we would rely on kernel to add the device-route for manual IPv6 routes. We broke that and now kernel would still add the device-route, however nm_platform_ip_route_sync() would delete it immediately after. That is because previously nm_platform_ip_route_sync() would ignore routes with rtm_protocol RTPRO_KERNEL. Now, it will sync and delete those too. Fix that by adding the device-route like we do it for IPv4. This also fixes an actual issue where the automatically added route always had route-metric 256. Instead, we now use the metric from ipv6.route-metric setting. Fixes: 6698bf58bb53fb07838c52ca67293dd5352ec31c
2017-09-19 09:40:13 +02:00
}
core: sync IPv6 pre-commit hook with IPv4 behavior The IPv4 pre-commit hook was called right before the config was committed, while the IPv6 one was called before commit in only one case (from nm_device_activate_ip6_config_commit). The IPv4 behavior is the intended behavior. Note that this doesn't have any actual effect yet, since nothing actually implements the IPv6 pre-commit hook
2014-08-13 14:24:45 -05:00
/* Allow setting MTU etc */
if (commit) {
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
NMUtilsIPv6IfaceId iid;
if (token && nm_utils_ipv6_interface_identifier_get_from_token (&iid, token)) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_set_ipv6_token (nm_device_get_platform (self),
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
nm_device_get_ip_ifindex (self),
iid);
}
core: sync IPv6 pre-commit hook with IPv4 behavior The IPv4 pre-commit hook was called right before the config was committed, while the IPv6 one was called before commit in only one case (from nm_device_activate_ip6_config_commit). The IPv4 behavior is the intended behavior. Note that this doesn't have any actual effect yet, since nothing actually implements the IPv6 pre-commit hook
2014-08-13 14:24:45 -05:00
}
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
success = nm_device_set_ip6_config (self, composite, commit);
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
g_object_unref (composite);
device: move setting v4_commit_first_time/v6_commit_first_time to the end of merge_and_apply()
2015-07-22 11:56:05 +02:00
if (commit)
priv->v6_commit_first_time = FALSE;
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
return success;
}
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
static gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
dhcp6_lease_change (NMDevice *self)
core: more DHCPv6 code shuffle No functional changes.
2011-10-07 12:06:26 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
NMSettingsConnection *settings_connection;
core: more DHCPv6 code shuffle No functional changes.
2011-10-07 12:06:26 -05:00
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
if (priv->dhcp6.ip6_config == NULL) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_DHCP6, "failed to get DHCPv6 config for rebind");
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
return FALSE;
core: more DHCPv6 code shuffle No functional changes.
2011-10-07 12:06:26 -05:00
}
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
g_assert (priv->dhcp6.client); /* sanity check */
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
settings_connection = nm_device_get_settings_connection (self);
g_assert (settings_connection);
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
/* Apply the updated config */
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (!ip6_config_merge_and_apply (self, TRUE)) {
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
_LOGW (LOGD_DHCP6, "failed to update IPv6 config in response to DHCP event");
return FALSE;
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
}
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
nm_dispatcher_call_device (NM_DISPATCHER_ACTION_DHCP6_CHANGE,
self,
NULL,
NULL, NULL, NULL);
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_remove_pending_action (self, NM_PENDING_ACTION_DHCP6, FALSE);
device: remove pending dhcp actions also in IP_DONE state When the IP status is IP_DONE and a DHCP transaction succeeds the 'dhcp4' and 'dhcp6' pending actions must be removed. Without this, a temporary link loss just after the activation would cause a DHCP restart and those actions would remain set, blocking the startup. https://bugzilla.redhat.com/show_bug.cgi?id=1330893
2016-05-10 16:34:50 +02:00
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
return TRUE;
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
}
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
static gboolean
dhcp6_restart_cb (gpointer user_data)
{
NMDevice *self = user_data;
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
priv->dhcp6.restart_id = 0;
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
if (!dhcp6_start (self, FALSE))
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
dhcp_schedule_restart (self, AF_INET6, NULL);
return FALSE;
}
static void
core: minor cleanup in dhcp_schedule_restart() Move creating the logging output inside the logging macro, so it is evaluated lazyly. Also, use a stack-allocated buffer. Drop the redundant @inet4 variable.
2017-10-02 13:11:31 +02:00
dhcp_schedule_restart (NMDevice *self,
int addr_family,
const char *reason)
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
guint tries_left;
core: minor cleanup in dhcp_schedule_restart() Move creating the logging output inside the logging macro, so it is evaluated lazyly. Also, use a stack-allocated buffer. Drop the redundant @inet4 variable.
2017-10-02 13:11:31 +02:00
char tries_str[255];
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
nm_assert_addr_family (addr_family);
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
core: minor cleanup in dhcp_schedule_restart() Move creating the logging output inside the logging macro, so it is evaluated lazyly. Also, use a stack-allocated buffer. Drop the redundant @inet4 variable.
2017-10-02 13:11:31 +02:00
tries_left = (addr_family == AF_INET)
? priv->dhcp4.num_tries_left
: priv->dhcp6.num_tries_left;
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
core: minor cleanup in dhcp_schedule_restart() Move creating the logging output inside the logging macro, so it is evaluated lazyly. Also, use a stack-allocated buffer. Drop the redundant @inet4 variable.
2017-10-02 13:11:31 +02:00
_LOGI ((addr_family == AF_INET) ? LOGD_DHCP4 : LOGD_DHCP6,
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
"scheduling DHCPv%c restart in %u seconds%s%s%s%s",
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
nm_utils_addr_family_to_char (addr_family),
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
DHCP_RESTART_TIMEOUT,
core: minor cleanup in dhcp_schedule_restart() Move creating the logging output inside the logging macro, so it is evaluated lazyly. Also, use a stack-allocated buffer. Drop the redundant @inet4 variable.
2017-10-02 13:11:31 +02:00
(tries_left != DHCP_NUM_TRIES_MAX)
? nm_sprintf_buf (tries_str, ", %u tries left", tries_left + 1)
: "",
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
NM_PRINT_FMT_QUOTED (reason, " (reason: ", reason, ")", ""));
core: minor cleanup in dhcp_schedule_restart() Move creating the logging output inside the logging macro, so it is evaluated lazyly. Also, use a stack-allocated buffer. Drop the redundant @inet4 variable.
2017-10-02 13:11:31 +02:00
if (addr_family == AF_INET) {
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
priv->dhcp4.restart_id = g_timeout_add_seconds (DHCP_RESTART_TIMEOUT,
dhcp4_restart_cb, self);
} else {
device: retry DHCPv6 when a lease expires Make DHCPv6 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:09:54 +02:00
priv->dhcp6.restart_id = g_timeout_add_seconds (DHCP_RESTART_TIMEOUT,
dhcp6_restart_cb, self);
}
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
}
core: consolidate DHCP failure handling code
2011-10-07 12:23:35 -05:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
dhcp6_fail (NMDevice *self, gboolean timeout)
core: consolidate DHCP failure handling code
2011-10-07 12:23:35 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: consolidate DHCP failure handling code
2011-10-07 12:23:35 -05:00
device: retry DHCPv6 when a lease expires Make DHCPv6 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:09:54 +02:00
_LOGD (LOGD_DHCP6, "DHCPv6 failed: timeout %d, num tries left %u",
timeout, priv->dhcp6.num_tries_left);
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
dhcp6_cleanup (self, CLEANUP_TYPE_DECONFIGURE, FALSE);
dhcp: DHCPv6 OtherConf failures should not be fatal OtherConf implies the address has already been delivered via RA, and possibly DNS too, meaning our IP configuration is already good enough. If nothing on the network bothers to reply to our DHCPv6 Information Requests, let's just run with the config we already have instead of tearing down the whole device.
2014-07-23 14:03:42 -05:00
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (priv->dhcp6.mode == NM_NDISC_DHCP_LEVEL_MANAGED) {
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
/* Don't fail if there are static addresses configured on
* the device, instead retry after some time.
*/
if ( priv->ip6_state == IP_DONE
&& priv->con_ip6_config
&& nm_ip6_config_get_num_addresses (priv->con_ip6_config)) {
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
dhcp_schedule_restart (self, AF_INET6, "device has IP addresses");
device: don't disconnect after DHCP failure when there are static IPs Don't disconnect the device when the DHCP renewal fails and there are already configured static IP addresses on the device. Instead, keep the device up and try DHCP again after some time. https://bugzilla.redhat.com/show_bug.cgi?id=1168388
2015-07-18 10:05:05 +02:00
return;
}
device: retry DHCPv6 when a lease expires Make DHCPv6 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:09:54 +02:00
if ( priv->dhcp6.num_tries_left == DHCP_NUM_TRIES_MAX
device: fix behavior for assumed DHCP connections When a DHCP connection is active and the DHCP server is temporarily unreachable, we restart DHCP for some times before failing the connection. From the user point of view, restarting NM (and thus assuming the existing connection) should not change this behavior. However, if NM is restarted while the server is temporarily down, at the moment we immediately fail because we consider the DHCP transaction our first try. Fix this by restoring the multiple tries when we detect that DHCP was active before because the connection is assumed.
2017-05-04 10:05:25 +02:00
&& (timeout || (priv->ip6_state == IP_CONF))
&& !priv->dhcp6.was_active)
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_activate_schedule_ip6_config_timeout (self);
device: fix behavior for assumed DHCP connections When a DHCP connection is active and the DHCP server is temporarily unreachable, we restart DHCP for some times before failing the connection. From the user point of view, restarting NM (and thus assuming the existing connection) should not change this behavior. However, if NM is restarted while the server is temporarily down, at the moment we immediately fail because we consider the DHCP transaction our first try. Fix this by restoring the multiple tries when we detect that DHCP was active before because the connection is assumed.
2017-05-04 10:05:25 +02:00
else if (priv->ip6_state == IP_DONE || priv->dhcp6.was_active) {
device: retry DHCPv6 when a lease expires Make DHCPv6 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:09:54 +02:00
/* Don't fail immediately when the lease expires but try to
* restart DHCP for a predefined number of times.
*/
if (priv->dhcp6.num_tries_left) {
priv->dhcp6.num_tries_left--;
device: add dhcp_schedule_restart() helper
2015-12-14 15:15:23 +01:00
dhcp_schedule_restart (self, AF_INET6, "lease expired");
device: retry DHCPv6 when a lease expires Make DHCPv6 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:09:54 +02:00
} else
nm_device_ip_method_failed (self, AF_INET6, NM_DEVICE_STATE_REASON_IP_CONFIG_EXPIRED);
} else
dhcp: fail the device if DHCP fails after having succeeded earlier (rh #1139326) If DHCP fails to renew or rebind a lease, fail the device since the IP config is no longer valid. Commit e2b7c482 was actually wrong for dhcp[4|6]_fail(), since (ip_state == IP_FAIL) will never be true if DHCP has ever been started, as IP_FAIL is only set from nm_device_activate_ip[4|6]_config_timeout(), which obviously will not be called in DHCP code paths if DHCP has previously succeeded.
2014-09-23 15:38:33 -05:00
g_warn_if_reached ();
dhcp: DHCPv6 OtherConf failures should not be fatal OtherConf implies the address has already been delivered via RA, and possibly DNS too, meaning our IP configuration is already good enough. If nothing on the network bothers to reply to our DHCPv6 Information Requests, let's just run with the config we already have instead of tearing down the whole device.
2014-07-23 14:03:42 -05:00
} else {
/* not a hard failure; just live with the RA info */
if (priv->ip6_state == IP_CONF)
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_activate_schedule_ip6_config_result (self);
dhcp: DHCPv6 OtherConf failures should not be fatal OtherConf implies the address has already been delivered via RA, and possibly DNS too, meaning our IP configuration is already good enough. If nothing on the network bothers to reply to our DHCPv6 Information Requests, let's just run with the config we already have instead of tearing down the whole device.
2014-07-23 14:03:42 -05:00
}
core: consolidate DHCP failure handling code
2011-10-07 12:23:35 -05:00
}
dhcp: merge TIMEOUT signal with DHCP_STATE_TIMEOUT No reason to have two signals for the same thing. Previously, the TIMEOUT signal was used for the internal overall DHCP transaction bound, while DHCP_STATE_TIMEOUT/DHC_TIMEOUT was a signal from the DHCP client itself that something had timed out. But in both cases the results should be the same, so just collapse the stand-alone TIMEOUT signal into the DHCP_STATE_TIMEOUT state.
2014-05-15 14:11:48 -05:00
static void
libnm, core, cli, tui: fix the capitalization of various types GLib/Gtk have mostly settled on the convention that two-letter acronyms in type names remain all-caps (eg, "IO"), but longer acronyms become initial-caps-only (eg, "Tcp"). NM was inconsistent, with most long acronyms using initial caps only (Adsl, Cdma, Dcb, Gsm, Olpc, Vlan), but others using all caps (DHCP, PPP, PPPOE, VPN). Fix libnm and src/ to use initial-caps only for all three-or-more-letter-long acronyms (and update nmcli and nmtui for the libnm changes).
2014-06-26 13:44:36 -04:00
dhcp6_timeout (NMDevice *self, NMDhcpClient *client)
dhcp: merge TIMEOUT signal with DHCP_STATE_TIMEOUT No reason to have two signals for the same thing. Previously, the TIMEOUT signal was used for the internal overall DHCP transaction bound, while DHCP_STATE_TIMEOUT/DHC_TIMEOUT was a signal from the DHCP client itself that something had timed out. But in both cases the results should be the same, so just collapse the stand-alone TIMEOUT signal into the DHCP_STATE_TIMEOUT state.
2014-05-15 14:11:48 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (priv->dhcp6.mode == NM_NDISC_DHCP_LEVEL_MANAGED)
dhcp: merge TIMEOUT signal with DHCP_STATE_TIMEOUT No reason to have two signals for the same thing. Previously, the TIMEOUT signal was used for the internal overall DHCP transaction bound, while DHCP_STATE_TIMEOUT/DHC_TIMEOUT was a signal from the DHCP client itself that something had timed out. But in both cases the results should be the same, so just collapse the stand-alone TIMEOUT signal into the DHCP_STATE_TIMEOUT state.
2014-05-15 14:11:48 -05:00
dhcp6_fail (self, TRUE);
else {
/* not a hard failure; just live with the RA info */
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
dhcp6_cleanup (self, CLEANUP_TYPE_DECONFIGURE, FALSE);
dhcp: merge TIMEOUT signal with DHCP_STATE_TIMEOUT No reason to have two signals for the same thing. Previously, the TIMEOUT signal was used for the internal overall DHCP transaction bound, while DHCP_STATE_TIMEOUT/DHC_TIMEOUT was a signal from the DHCP client itself that something had timed out. But in both cases the results should be the same, so just collapse the stand-alone TIMEOUT signal into the DHCP_STATE_TIMEOUT state.
2014-05-15 14:11:48 -05:00
if (priv->ip6_state == IP_CONF)
nm_device_activate_schedule_ip6_config_result (self);
}
}
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
static void
libnm, core, cli, tui: fix the capitalization of various types GLib/Gtk have mostly settled on the convention that two-letter acronyms in type names remain all-caps (eg, "IO"), but longer acronyms become initial-caps-only (eg, "Tcp"). NM was inconsistent, with most long acronyms using initial caps only (Adsl, Cdma, Dcb, Gsm, Olpc, Vlan), but others using all caps (DHCP, PPP, PPPOE, VPN). Fix libnm and src/ to use initial-caps only for all three-or-more-letter-long acronyms (and update nmcli and nmtui for the libnm changes).
2014-06-26 13:44:36 -04:00
dhcp6_state_changed (NMDhcpClient *client,
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
NMDhcpState state,
dhcp: pass IP config in state signal Just pass it in the state change signal.
2014-07-01 09:48:58 -05:00
NMIP6Config *ip6_config,
dhcp: pass DHCP options with BOUND state change The options hash is never used except for BOUND events, so don't bother caching it in the DHCP client object. Just pass it along with the BOUND state change, like the IP configuration object.
2014-07-01 12:30:29 -05:00
GHashTable *options,
device: accept multiple addresses in a DHCPv6 lease When the DHCPv6 lease received from the server contains multiple addresses, dhclient generates a new BOUND event for each of them. Instead of overwriting the previous IP6 configuration for each BOUND event, we should try to detect if the new configuration belongs to the same lease and merge its addresses with the existing one in such case. This allows NetworkManager to configure multiple addresses on an interface via DHCPv6. https://bugzilla.gnome.org/show_bug.cgi?id=681764 https://bugzilla.redhat.com/show_bug.cgi?id=1244293
2015-08-04 11:30:03 +02:00
const char *event_id,
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
gpointer user_data)
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
core/dhcp: use addr-family parameter for instead of boolean In many cases we want to treat IPv4 and IPv6 generically. That looks nicer if we distingish by an @addr_family integer, instead of a boolean. Replace the @is_ipv6 boolean with an @addr_family paramter. The @is_ipv6 boolean is inconsistent with other places where we use @is_ipv4 to indicate the opposite. Eventually, we should use @addr_family everywhere. Also, at the call site it's not immediately clear what TRUE/FALSE means, here AF_INET/AF_INET6 is better.
2017-09-11 11:30:48 +02:00
g_return_if_fail (nm_dhcp_client_get_addr_family (client) == AF_INET6);
dhcp: pass IP config in state signal Just pass it in the state change signal.
2014-07-01 09:48:58 -05:00
g_return_if_fail (!ip6_config || NM_IS_IP6_CONFIG (ip6_config));
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DHCP6, "new DHCPv6 client state %d", state);
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
switch (state) {
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
case NM_DHCP_STATE_BOUND:
device: accept multiple addresses in a DHCPv6 lease When the DHCPv6 lease received from the server contains multiple addresses, dhclient generates a new BOUND event for each of them. Instead of overwriting the previous IP6 configuration for each BOUND event, we should try to detect if the new configuration belongs to the same lease and merge its addresses with the existing one in such case. This allows NetworkManager to configure multiple addresses on an interface via DHCPv6. https://bugzilla.gnome.org/show_bug.cgi?id=681764 https://bugzilla.redhat.com/show_bug.cgi?id=1244293
2015-08-04 11:30:03 +02:00
/* If the server sends multiple IPv6 addresses, we receive a state
* changed event for each of them. Use the event ID to merge IPv6
* addresses from the same transaction into a single configuration.
*/
if ( ip6_config
&& event_id
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
&& priv->dhcp6.event_id
&& !strcmp (event_id, priv->dhcp6.event_id)) {
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
NMDedupMultiIter ipconf_iter;
const NMPlatformIP6Address *a;
nm_ip_config_iter_ip6_address_for_each (&ipconf_iter, ip6_config, &a)
nm_ip6_config_add_address (priv->dhcp6.ip6_config, a);
device: accept multiple addresses in a DHCPv6 lease When the DHCPv6 lease received from the server contains multiple addresses, dhclient generates a new BOUND event for each of them. Instead of overwriting the previous IP6 configuration for each BOUND event, we should try to detect if the new configuration belongs to the same lease and merge its addresses with the existing one in such case. This allows NetworkManager to configure multiple addresses on an interface via DHCPv6. https://bugzilla.gnome.org/show_bug.cgi?id=681764 https://bugzilla.redhat.com/show_bug.cgi?id=1244293
2015-08-04 11:30:03 +02:00
} else {
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
g_clear_object (&priv->dhcp6.ip6_config);
g_clear_pointer (&priv->dhcp6.event_id, g_free);
device: accept multiple addresses in a DHCPv6 lease When the DHCPv6 lease received from the server contains multiple addresses, dhclient generates a new BOUND event for each of them. Instead of overwriting the previous IP6 configuration for each BOUND event, we should try to detect if the new configuration belongs to the same lease and merge its addresses with the existing one in such case. This allows NetworkManager to configure multiple addresses on an interface via DHCPv6. https://bugzilla.gnome.org/show_bug.cgi?id=681764 https://bugzilla.redhat.com/show_bug.cgi?id=1244293
2015-08-04 11:30:03 +02:00
if (ip6_config) {
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
priv->dhcp6.ip6_config = g_object_ref (ip6_config);
priv->dhcp6.event_id = g_strdup (event_id);
nm_dhcp6_config_set_options (priv->dhcp6.config, options);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_DHCP6_CONFIG);
device: accept multiple addresses in a DHCPv6 lease When the DHCPv6 lease received from the server contains multiple addresses, dhclient generates a new BOUND event for each of them. Instead of overwriting the previous IP6 configuration for each BOUND event, we should try to detect if the new configuration belongs to the same lease and merge its addresses with the existing one in such case. This allows NetworkManager to configure multiple addresses on an interface via DHCPv6. https://bugzilla.gnome.org/show_bug.cgi?id=681764 https://bugzilla.redhat.com/show_bug.cgi?id=1244293
2015-08-04 11:30:03 +02:00
}
core: fix stale DHCPv6 information for dispatcher lease-change events (bgo #721002) dhcp6_lease_change() needs to be called *after* updating the DHCP config object to ensure that the dispatcher gets the new values.
2014-01-06 16:06:49 -06:00
}
device: retry DHCPv6 when a lease expires Make DHCPv6 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:09:54 +02:00
priv->dhcp6.num_tries_left = DHCP_NUM_TRIES_MAX;
device: clean up ip6 configuration flow IP6 configuration is now stored in ac_ip6_config and dhcp6_ip6_config and passing them as function arguments is avoided. Written with Dan Williams.
2013-06-14 21:42:22 +02:00
if (priv->ip6_state == IP_CONF) {
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
if (priv->dhcp6.ip6_config == NULL) {
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
nm_device_ip_method_failed (self, AF_INET6, NM_DEVICE_STATE_REASON_DHCP_FAILED);
device: clean up ip6 configuration flow IP6 configuration is now stored in ac_ip6_config and dhcp6_ip6_config and passing them as function arguments is avoided. Written with Dan Williams.
2013-06-14 21:42:22 +02:00
break;
}
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_activate_schedule_ip6_config_result (self);
device: clean up ip6 configuration flow IP6 configuration is now stored in ac_ip6_config and dhcp6_ip6_config and passing them as function arguments is avoided. Written with Dan Williams.
2013-06-14 21:42:22 +02:00
} else if (priv->ip6_state == IP_DONE)
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
if (!dhcp6_lease_change (self))
dhcp6_fail (self, FALSE);
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
break;
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
case NM_DHCP_STATE_TIMEOUT:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
dhcp6_timeout (self, client);
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
break;
core: better handle DHCP expiry/nak during initial lease acquisition (bgo #739482) When dhclient trieds to request a previous lease and the server NAKs that lease, dhclient emits the EXPIRE state. dhcpcd has also been known to emit the 'nak' state for the same reason. (systemd's DHCP client code does not push a NAK up to NetworkManager, but jumps to the REBOOT state instead, so it is unaffected by this issue.) NetworkManager saw the expire during IP configuration and treated that as full activation failure. The connection would be restarted, the same lease requested, and the same NAK delivered, over and over. Before a lease is acquired, there is (by definition) no lease to expire, so these events should be ignored. We do, however, still want to handle abnormal failures, which is why this patch splits the EXPIRE case from the FAIL case and handles them separately. https://bugzilla.gnome.org/show_bug.cgi?id=739482
2014-12-11 15:36:27 -06:00
case NM_DHCP_STATE_EXPIRE:
/* Ignore expiry before we even have a lease (NAK, old lease, etc) */
if (priv->ip6_state != IP_CONF)
dhcp6_fail (self, FALSE);
break;
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
case NM_DHCP_STATE_DONE:
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
/* In IPv6 info-only mode, the client doesn't handle leases so it
* may exit right after getting a response from the server. That's
* normal. In that case we just ignore the exit.
*/
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (priv->dhcp6.mode == NM_NDISC_DHCP_LEVEL_OTHERCONF)
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
break;
all: cleanup switch fall-through comments for -Wimplicit-fallthrough warning The -Wimplicit-fallthrough=3 warning is quite flexible of accepting a fall-through warning. Some comments were missing or not detected correctly. Thereby, also change all other comments to follow the exact same pattern.
2017-02-06 14:42:47 +01:00
/* fall through */
dhcp: simplify DHCP states The existing DHC_* states are pretty specific to dhclient, and aren't useful for more generalized DHCP. NetworkManager wasn't using many of the states anyway, and doesn't need to differentiate between states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states into the ones we really care about.
2014-05-15 12:49:11 -05:00
case NM_DHCP_STATE_FAIL:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
dhcp6_fail (self, FALSE);
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
break;
default:
break;
}
}
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
static void
dhcp6_prefix_delegated (NMDhcpClient *client,
NMPlatformIP6Address *prefix,
gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
/* Just re-emit. The device just contributes the prefix to the
* pool in NMPolicy, which decides about subnet allocation
* on the shared devices. */
g_signal_emit (self, signals[IP6_PREFIX_DELEGATED], 0, prefix);
}
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
static gboolean
dhcp6_start_with_link_ready (NMDevice *self, NMConnection *connection)
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
NMSettingIPConfig *s_ip6;
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
GByteArray *tmp = NULL;
core: use IP interface hardware address for IP-level operations The IP interface may have its own hardware address (like the net port for WWAN devices) and that's the hardware address that must be used for DHCP and IPv6 SLAAC, not the hardware address (if any) of the NMDevice itself. This patch does change the NMDevice hardware address property to always be the Device's hardware address, instead of the IP interface hardware address. This means that ADSL and WWAN will no longer change their hardware address to the hardware address of their IP interface. But in all these cases, the hardware address is non-existent (PPP) or transient and meaningless (WWAN/ADSL).
2014-04-10 18:02:52 -05:00
const guint8 *hw_addr;
size_t hw_addr_len = 0;
device: check ext_ip6_config_captured for ll_addr in dhcp6_start_with_link_ready() We should not check ip6_config for the link local address because ip6_config contains the merged settings we want to configure, not the addresses that are actually configured on the device. Check ext_ip6_config_captured for that. Also, reuse nm_ip6_config_get_address_first_nontentative() which only takes an address after it survived DAD.
2016-01-30 22:31:37 +01:00
const NMPlatformIP6Address *ll_addr = NULL;
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
g_assert (connection);
dhcp: pass individual options to DHCP instead of NMSettingIPxConfig
2014-07-11 12:50:17 -05:00
s_ip6 = nm_connection_get_setting_ip6_config (connection);
g_assert (s_ip6);
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
device: fail DHCPv6 if a link-local address is not present Instead of throwing an assertion, fail DHCPv6 when a IPv6 link-local address is not configured on the device. There are different reasons why the assertion may fail: for example the address was removed externally; or the device is gone (and thus the platform already received the notification of addresses removal) but the device is still connecting because its disposal happens in an idle callback. None of these deserves an assertion, which should only be for programming errors. https://bugzilla.redhat.com/show_bug.cgi?id=1432251
2017-03-14 23:35:35 +01:00
if (priv->ext_ip6_config_captured)
ll_addr = nm_ip6_config_get_address_first_nontentative (priv->ext_ip6_config_captured, TRUE);
if (!ll_addr) {
_LOGW (LOGD_DHCP6, "can't start DHCPv6: no link-local address");
return FALSE;
}
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
hw_addr = nm_platform_link_get_address (nm_device_get_platform (self), nm_device_get_ip_ifindex (self), &hw_addr_len);
core: use IP interface hardware address for IP-level operations The IP interface may have its own hardware address (like the net port for WWAN devices) and that's the hardware address that must be used for DHCP and IPv6 SLAAC, not the hardware address (if any) of the NMDevice itself. This patch does change the NMDevice hardware address property to always be the Device's hardware address, instead of the IP interface hardware address. This means that ADSL and WWAN will no longer change their hardware address to the hardware address of their IP interface. But in all these cases, the hardware address is non-existent (PPP) or transient and meaningless (WWAN/ADSL).
2014-04-10 18:02:52 -05:00
if (hw_addr_len) {
tmp = g_byte_array_sized_new (hw_addr_len);
g_byte_array_append (tmp, hw_addr, hw_addr_len);
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
}
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
priv->dhcp6.client = nm_dhcp_manager_start_ip6 (nm_dhcp_manager_get (),
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
nm_device_get_multi_index (self),
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
nm_device_get_ip_iface (self),
dhcp: pass ifindex to DHCP clients
2014-04-03 13:13:17 -05:00
nm_device_get_ip_ifindex (self),
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
tmp,
device: check ext_ip6_config_captured for ll_addr in dhcp6_start_with_link_ready() We should not check ip6_config for the link local address because ip6_config contains the merged settings we want to configure, not the addresses that are actually configured on the device. Check ext_ip6_config_captured for that. Also, reuse nm_ip6_config_get_address_first_nontentative() which only takes an address after it survived DAD.
2016-01-30 22:31:37 +01:00
&ll_addr->address,
core: use nm_connection_get_id() and nm_connection_get_uuid() to simplify code
2011-03-08 13:41:28 +01:00
nm_connection_get_uuid (connection),
core: use ipv4.route-table setting for other IPv4 routes Including device-routes, default-route, DHCPv4, IPv4LL.
2017-09-28 14:40:12 +02:00
nm_device_get_route_table (self, AF_INET6, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET6),
core, clients: implement dhcp-send-hostname for IPv6 Now that NMSettingIP6Config inherits the dhcp-send-hostname property from NMSettingIPConfig, fix things up so that it actually gets used. (Note that this changes behavior: previously if ip6.dhcp-hostname was unset, no hostname would be sent. Now, the system hostname will be set. Also, ifcfg-rh does not currently support this property, so there is no way to disable this...)
2014-11-04 10:46:05 -05:00
nm_setting_ip_config_get_dhcp_send_hostname (s_ip6),
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
nm_setting_ip_config_get_dhcp_hostname (s_ip6),
device: enable support for ipv6.dhcp-timeout - cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().
2017-09-11 10:43:48 +02:00
get_dhcp_timeout (self, AF_INET6),
dhcp: refactor dhcp code to use @dhcp_anycast_addr as #GByteArray type At a later point, we will have to make a copy of @dhcp_anycast_addr to start the client asynchronously. Although the length of the guint8 array *should* always be 6 byte (being a MAC address), it's nicer to just pass on the GByteArray instance instead, which knows how many byte are actually set. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-10 16:11:21 +01:00
priv->dhcp_anycast_address,
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
(priv->dhcp6.mode == NM_NDISC_DHCP_LEVEL_OTHERCONF) ? TRUE : FALSE,
dhcp-manager: add ability to specify the number of IPv6 prefixes to request Utilizes RFC 3633 prefix option in role of requesting router to ask the delegating router for prefixes. In future we'll be able to use the addresses from those prefixes on ipv6.method=shared connections.
2016-10-31 23:30:37 +01:00
nm_setting_ip6_config_get_ip6_privacy (NM_SETTING_IP6_CONFIG (s_ip6)),
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
priv->dhcp6.needed_prefixes);
dhcp: pass device hardware address to DHCP Gets used for stuff like the interface DUID for DHCPv6.
2012-06-13 13:28:55 -05:00
if (tmp)
g_byte_array_free (tmp, TRUE);
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
if (priv->dhcp6.client) {
priv->dhcp6.state_sigid = g_signal_connect (priv->dhcp6.client,
dhcp: refactor using named defines for signal names instead of plain string Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-11 14:02:24 +01:00
NM_DHCP_CLIENT_SIGNAL_STATE_CHANGED,
core: split DHCPv4 and DHCPv6 state and lease handling code
2011-10-07 12:05:51 -05:00
G_CALLBACK (dhcp6_state_changed),
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
self);
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
priv->dhcp6.prefix_sigid = g_signal_connect (priv->dhcp6.client,
NM_DHCP_CLIENT_SIGNAL_PREFIX_DELEGATED,
G_CALLBACK (dhcp6_prefix_delegated),
self);
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
}
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
dhcp: set @was_active flag for external activations Set the @was_active flag for external activations with DHCP, so that DHCP is retried multiple times in case of failure, as we do for managed connections when the lease expires and for assumed connections. Fixes test: renewal_gw_after_dhcp_outage_for_assumed_var1 Fixes: e3113fdc4b01d79080911b7450fc032dc0a85108
2017-05-08 08:44:51 +02:00
if (nm_device_sys_iface_state_is_external_or_assume (self))
dhcp: set @was_active on ipv6 when assuming a device with dhcp ipv6 conf Due to a typo the flag was set on ipv4 Fixes: ddfeed4530bb0ade4249025930da4f0456026d9f
2017-10-06 10:28:15 +02:00
priv->dhcp6.was_active = TRUE;
device: fix behavior for assumed DHCP connections When a DHCP connection is active and the DHCP server is temporarily unreachable, we restart DHCP for some times before failing the connection. From the user point of view, restarting NM (and thus assuming the existing connection) should not change this behavior. However, if NM is restarted while the server is temporarily down, at the moment we immediately fail because we consider the DHCP transaction our first try. Fix this by restoring the multiple tries when we detect that DHCP was active before because the connection is assumed.
2017-05-04 10:05:25 +02:00
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
return !!priv->dhcp6.client;
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
}
core: wait with "startup complete" for both IPv4 and IPv6 dynamic configuration In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until both IPv4 and IPv6 are ready. This especially has an effect on nm-online/NetworkManager-wait-online.service, which blocks until configuration of both IPv4 and IPv6 is ready. We queue a pending_action when automatic configuration starts and remove it again, when we receive an address. Before, "startup complete" was reached when either one of the two IP protocols was configured. https://bugzilla.redhat.com/show_bug.cgi?id=1086906 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-14 17:57:56 +02:00
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
static gboolean
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
dhcp6_start (NMDevice *self, gboolean wait_for_ll)
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
NMSettingIPConfig *s_ip6;
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
nm_exported_object_clear_and_unexport (&priv->dhcp6.config);
priv->dhcp6.config = nm_dhcp6_config_new ();
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
g_warn_if_fail (priv->dhcp6.ip6_config == NULL);
g_clear_object (&priv->dhcp6.ip6_config);
g_clear_pointer (&priv->dhcp6.event_id, g_free);
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
g_assert (connection);
s_ip6 = nm_connection_get_setting_ip6_config (connection);
if (!nm_setting_ip_config_get_may_fail (s_ip6) ||
!strcmp (nm_setting_ip_config_get_method (s_ip6), NM_SETTING_IP6_CONFIG_METHOD_DHCP))
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_add_pending_action (self, NM_PENDING_ACTION_DHCP6, TRUE);
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
if (wait_for_ll) {
NMActStageReturn ret;
/* ensure link local is ready... */
ret = linklocal6_start (self);
if (ret == NM_ACT_STAGE_RETURN_POSTPONE) {
/* success; wait for the LL address to show up */
return TRUE;
}
/* success; already have the LL address; kick off DHCP */
device: remove unneeded activation-stage result NM_ACT_STAGE_RETURN_FINISH We can express FINISH by returning SUCCESS and not set out_config in act_stage3_ip4_config_start().
2016-08-29 15:33:33 +02:00
g_assert (ret == NM_ACT_STAGE_RETURN_SUCCESS);
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
}
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
if (!dhcp6_start_with_link_ready (self, connection))
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
return FALSE;
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
return TRUE;
dhcp6: first stab at autoconf otherconf/managed mode support
2010-01-27 16:20:09 -08:00
}
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
gboolean
nm_device_dhcp6_renew (NMDevice *self, gboolean release)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
g_return_val_if_fail (priv->dhcp6.client != NULL, FALSE);
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_DHCP6, "DHCPv6 lease renewal requested");
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
/* Terminate old DHCP instance and release the old lease */
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
dhcp6_cleanup (self, CLEANUP_TYPE_DECONFIGURE, release);
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
/* Start DHCP again on the interface */
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
return dhcp6_start (self, FALSE);
core: support renaming of NMDevice (changes of ifname) https://bugzilla.gnome.org/show_bug.cgi?id=726177 https://bugzilla.redhat.com/show_bug.cgi?id=907836 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-28 21:25:34 +01:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
/*
* Called on the requesting interface when a subnet can't be obtained
* from known prefixes for a newly active shared connection.
*/
void
nm_device_request_ip6_prefixes (NMDevice *self, int needed_prefixes)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
priv->dhcp6.needed_prefixes = needed_prefixes;
if (priv->dhcp6.client) {
_LOGD (LOGD_IP6, "ipv6-pd: asking DHCPv6 for %d prefixes", needed_prefixes);
nm_device_dhcp6_renew (self, FALSE);
} else {
_LOGI (LOGD_IP6, "ipv6-pd: device doesn't use DHCPv6, can't request prefixes");
}
}
gboolean
nm_device_needs_ip6_subnet (NMDevice *self)
{
return NM_DEVICE_GET_PRIVATE (self)->needs_ip6_subnet;
}
/*
* Called on the ipv6.method=shared interface when a new subnet is allocated
* or the prefix from which it is allocated is renewed.
*/
void
nm_device_use_ip6_subnet (NMDevice *self, const NMPlatformIP6Address *subnet)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMPlatformIP6Address address = *subnet;
if (!priv->ac_ip6_config)
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
priv->ac_ip6_config = _ip6_config_new (self);
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
/* Assign a ::1 address in the subnet for us. */
address.address.s6_addr32[3] |= htonl (1);
nm_ip6_config_add_address (priv->ac_ip6_config, &address);
_LOGD (LOGD_IP6, "ipv6-pd: using %s address (preferred for %u seconds)",
nm_utils_inet6_ntop (&address.address, NULL),
subnet->preferred);
/* This also updates the ndisc if there are actual changes. */
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (!ip6_config_merge_and_apply (self, TRUE))
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
_LOGW (LOGD_IP6, "ipv6-pd: failed applying IP6 config for connection sharing");
}
/*
* Called whenever the policy picks a default IPv6 device.
* The ipv6.method=shared devices just reuse its DNS configuration.
*/
void
nm_device_copy_ip6_dns_config (NMDevice *self, NMDevice *from_device)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMIP6Config *from_config = NULL;
core: merge IPv4 and IPv6 implementations in NMDnsManager
2017-11-08 21:31:01 +01:00
guint i, len;
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
if (priv->ac_ip6_config) {
nm_ip6_config_reset_nameservers (priv->ac_ip6_config);
nm_ip6_config_reset_searches (priv->ac_ip6_config);
} else
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
priv->ac_ip6_config = _ip6_config_new (self);
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
if (from_device)
from_config = nm_device_get_ip6_config (from_device);
if (!from_config)
return;
core: merge IPv4 and IPv6 implementations in NMDnsManager
2017-11-08 21:31:01 +01:00
len = nm_ip6_config_get_num_nameservers (from_config);
for (i = 0; i < len; i++) {
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
nm_ip6_config_add_nameserver (priv->ac_ip6_config,
nm_ip6_config_get_nameserver (from_config, i));
}
core: merge IPv4 and IPv6 implementations in NMDnsManager
2017-11-08 21:31:01 +01:00
len = nm_ip6_config_get_num_searches (from_config);
for (i = 0; i < len; i++) {
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
nm_ip6_config_add_search (priv->ac_ip6_config,
core: merge IPv4 and IPv6 implementations in NMDnsManager
2017-11-08 21:31:01 +01:00
nm_ip6_config_get_search (from_config, i));
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
}
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (!ip6_config_merge_and_apply (self, TRUE))
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
_LOGW (LOGD_IP6, "ipv6-pd: failed applying DNS config for connection sharing");
}
/*****************************************************************************/
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
static void
linklocal6_cleanup (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core,libnm: use nm_clear_g_source() where possible Replacement was done with commands: spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir src spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir libnm where nm_clear_g_source.cocci contains: @@ expression e; @@ - if (e) { - g_source_remove (e); - e = 0; - } + nm_clear_g_source (&e);
2016-01-04 09:46:22 +01:00
nm_clear_g_source (&priv->linklocal6_timeout_id);
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
}
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
static void
linklocal6_failed (NMDevice *self)
{
linklocal6_cleanup (self);
nm_device_activate_schedule_ip6_config_timeout (self);
}
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
static gboolean
linklocal6_timeout_cb (gpointer user_data)
{
NMDevice *self = user_data;
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "linklocal6: waiting for link-local addresses failed due to timeout");
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
linklocal6_failed (self);
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
return G_SOURCE_REMOVE;
}
static void
linklocal6_complete (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
const char *method;
g_assert (priv->linklocal6_timeout_id);
device: synchronize IPv6 configuration in stage3 (take 2) Most of the IPv6 methods require a non-tentative link local address configured on the interface; we look at priv->ip6_config to determine if such address exist. If the configuration is out-of-sync, we may proceed with configuration when the link-local address does not exist or is still tentative, especially because we toggle the "disable_ipv6" sysctl parameter just before, which clears all IPv6 addresses on the interface. Ensure that priv->ext_ip6_config_captured is up-to-date before continuing with the IPv6 configuration, and use it to determine whether suitable addresses are present. Fixes test: @ipv6_set_ra_announced_mtu Fixes: 8f4caab60196132c2fd0eb4a444f93f78f130e8e
2017-05-06 10:56:21 +02:00
g_assert (priv->ext_ip6_config_captured);
g_assert (nm_ip6_config_get_address_first_nontentative (priv->ext_ip6_config_captured, TRUE));
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
linklocal6_cleanup (self);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
g_assert (connection);
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG);
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "linklocal6: waiting for link-local addresses successful, continue with method %s", method);
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
if ( strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_AUTO) == 0
|| strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_SHARED) == 0) {
core: fail IPv6 router discovery if IID cannot be generated If the IID cannot be generated, the IPv6 address resulting from the combination of an advertised prefix and 64-bits of zero is both wrong and quite likely to clash with some other machine on the network that doesn't implement IPv6 quite right either. Require an valid interface identifier. If NetworkManager doesn't know how to generate one, then we should fix NM to do so.
2014-07-22 16:24:07 -05:00
if (!addrconf6_start_with_link_ready (self)) {
/* Time out IPv6 instead of failing the entire activation */
nm_device_activate_schedule_ip6_config_timeout (self);
}
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
} else if (strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_DHCP) == 0) {
if (!dhcp6_start_with_link_ready (self, connection)) {
/* Time out IPv6 instead of failing the entire activation */
nm_device_activate_schedule_ip6_config_timeout (self);
}
core: fail IPv6 router discovery if IID cannot be generated If the IID cannot be generated, the IPv6 address resulting from the combination of an advertised prefix and 64-bits of zero is both wrong and quite likely to clash with some other machine on the network that doesn't implement IPv6 quite right either. Require an valid interface identifier. If NetworkManager doesn't know how to generate one, then we should fix NM to do so.
2014-07-22 16:24:07 -05:00
} else if (strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_LINK_LOCAL) == 0)
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
nm_device_activate_schedule_ip6_config_result (self);
else
g_return_if_fail (FALSE);
}
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
static void
check_and_add_ipv6ll_addr (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
int ip_ifindex = nm_device_get_ip_ifindex (self);
struct in6_addr lladdr;
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
NMConnection *connection;
NMSettingIP6Config *s_ip6 = NULL;
GError *error = NULL;
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
if (priv->nm_ipv6ll == FALSE)
return;
if (priv->ip6_config) {
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
NMDedupMultiIter ipconf_iter;
const NMPlatformIP6Address *addr;
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
nm_ip_config_iter_ip6_address_for_each (&ipconf_iter, priv->ip6_config, &addr) {
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
if ( IN6_IS_ADDR_LINKLOCAL (&addr->address)
platform/trivial: rename NMPlatformIP6Address's "flags" field to "n_ifa_flags" There are far too many "flags". Rename the "flags" to "n_ifa_flags" which reminds to "ifa_flags" in 'struct ifaddrmsg', but with a distinctive "n_" prefix.
2016-02-29 16:23:16 +01:00
&& !(addr->n_ifa_flags & IFA_F_DADFAILED)) {
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
/* Already have an LL address, nothing to do */
return;
}
}
}
memset (&lladdr, 0, sizeof (lladdr));
lladdr.s6_addr16[0] = htons (0xfe80);
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
connection = nm_device_get_applied_connection (self);
if (connection)
s_ip6 = NM_SETTING_IP6_CONFIG (nm_connection_get_setting_ip6_config (connection));
if (s_ip6 && nm_setting_ip6_config_get_addr_gen_mode (s_ip6) == NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY) {
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
NMUtilsStableType stable_type;
const char *stable_id;
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
stable_id = _get_stable_id (self, connection, &stable_type);
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
if ( !stable_id
|| !nm_utils_ipv6_addr_set_stable_privacy (stable_type,
&lladdr,
nm_device_get_iface (self),
stable_id,
priv->linklocal6_dad_counter++,
&error)) {
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
_LOGW (LOGD_IP6, "linklocal6: failed to generate an address: %s", error->message);
g_clear_error (&error);
linklocal6_failed (self);
return;
}
_LOGD (LOGD_IP6, "linklocal6: using IPv6 stable-privacy addressing");
} else {
NMUtilsIPv6IfaceId iid;
if (priv->linklocal6_timeout_id) {
/* We already started and attempt to add a LL address. For the EUI-64
* mode we can't pick a new one, we'll just fail. */
_LOGW (LOGD_IP6, "linklocal6: DAD failed for an EUI-64 address");
linklocal6_failed (self);
return;
}
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
if (!nm_device_get_ip_iface_identifier (self, &iid, TRUE)) {
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
_LOGW (LOGD_IP6, "linklocal6: failed to get interface identifier; IPv6 cannot continue");
return;
}
_LOGD (LOGD_IP6, "linklocal6: using EUI-64 identifier to generate IPv6LL address");
all: fix the identfier typo
2016-05-27 18:19:55 +02:00
nm_utils_ipv6_addr_set_interface_identifier (&lladdr, iid);
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
}
_LOGD (LOGD_IP6, "linklocal6: adding IPv6LL address %s", nm_utils_inet6_ntop (&lladdr, NULL));
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_ip6_address_add (nm_device_get_platform (self),
platform: add self argument to platform functions Most nm_platform_*() functions operate on the platform singleton nm_platform_get(). That made sense because the NMPlatform instance was mainly to hook fake platform for testing. While the implicit argument saved some typing, I think explicit is better. Especially, because NMPlatform could become a more usable object then just a hook for testing. With this change, NMPlatform instances can be used individually, not only as a singleton instance. Before this change, the constructor of NMLinuxPlatform could not call any nm_platform_*() functions because the singleton was not yet initialized. We could only instantiate an incomplete instance, register it via nm_platform_setup(), and then complete initialization via singleton->setup(). With this change, we can create and fully initialize NMPlatform instances before/without setting them up them as singleton. Also, currently there is no clear distinction between functions that operate on the NMPlatform instance, and functions that can be used stand-alone (e.g. nm_platform_ip4_address_to_string()). The latter can not be mocked for testing. With this change, the distinction becomes obvious. That is also useful because it becomes clearer which functions make use of the platform cache and which not. Inside nm-linux-platform.c, continue the pattern that the self instance is named @platform. That makes sense because its type is NMPlatform, and not NMLinuxPlatform what we would expect from a paramter named @self. This is a major diff that causes some pain when rebasing. Try to rebase to the parent commit of this commit as a first step. Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
ip_ifindex,
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
lladdr,
64,
platform: refactor order of peer-address argument in ip_address_add() function The peer-address seems less important then the prefix-length. Also, nm_platform_ip4_address_delete() has the peer-address argument as last. Soon ip4_address_get() also receives a peer-address argument, so get the order right first.
2015-10-10 19:58:59 +02:00
in6addr_any,
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
NM_PLATFORM_LIFETIME_PERMANENT,
NM_PLATFORM_LIFETIME_PERMANENT,
0)) {
_LOGW (LOGD_IP6, "failed to add IPv6 link-local address %s",
nm_utils_inet6_ntop (&lladdr, NULL));
}
}
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
static NMActStageReturn
linklocal6_start (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
const char *method;
linklocal6_cleanup (self);
device: synchronize IPv6 configuration in stage3 (take 2) Most of the IPv6 methods require a non-tentative link local address configured on the interface; we look at priv->ip6_config to determine if such address exist. If the configuration is out-of-sync, we may proceed with configuration when the link-local address does not exist or is still tentative, especially because we toggle the "disable_ipv6" sysctl parameter just before, which clears all IPv6 addresses on the interface. Ensure that priv->ext_ip6_config_captured is up-to-date before continuing with the IPv6 configuration, and use it to determine whether suitable addresses are present. Fixes test: @ipv6_set_ra_announced_mtu Fixes: 8f4caab60196132c2fd0eb4a444f93f78f130e8e
2017-05-06 10:56:21 +02:00
if ( priv->ext_ip6_config_captured
&& nm_ip6_config_get_address_first_nontentative (priv->ext_ip6_config_captured, TRUE))
device: remove unneeded activation-stage result NM_ACT_STAGE_RETURN_FINISH We can express FINISH by returning SUCCESS and not set out_config in act_stage3_ip4_config_start().
2016-08-29 15:33:33 +02:00
return NM_ACT_STAGE_RETURN_SUCCESS;
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
g_assert (connection);
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG);
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "linklocal6: starting IPv6 with method '%s', but the device has no link-local addresses configured. Wait.", method);
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
check_and_add_ipv6ll_addr (self);
device: increase IPv6LL DAD timeout (rh #1101809) Depending on the network and the values of the 'dad_transmits' and 'retrans_timeout_ms' sysctls, DAD for the IPv6LL address can take quite a while. Obviously there must be some upper bound on the timeout, but 5 seconds seems a bit low. In this case it was observed to be ~12 seconds but the sysctl values are unknown. In any case, we can't predict the network/config so being a bit more lenient here makes sense. https://bugzilla.redhat.com/show_bug.cgi?id=1101809
2015-09-17 09:55:23 -05:00
/* Depending on the network and what the 'dad_transmits' and 'retrans_time_ms'
* sysctl values are, DAD for the IPv6LL address may take quite a while.
* FIXME: use dad/retrans sysctl values if they are higher than a minimum time.
* (rh #1101809)
*/
priv->linklocal6_timeout_id = g_timeout_add_seconds (15, linklocal6_timeout_cb, self);
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
return NM_ACT_STAGE_RETURN_POSTPONE;
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
device: make the MTU globally configurable via connection-defaults This allows a user to restore the previous behavior where NetworkManager would not reconfigure the MTU during device activation, if no MTU is available (commit "22e8af6 device: set a per-device default MTU on activation"). Well, not exactly. The previous behavior was to use per-connection configuration, then DHCP provided value, or finally leave the MTU unspecified. Now, we prefer a per-connection configuration, followed by a global connection default. If "ethernet.mtu=0", the MTU is left unspecified. In absense of a global connection default, the value from DHCP is used or finally a per-device-type default. That is effectively 1500 for most types, except for infiniband where the MTU is still left unspecified.
2017-01-17 13:11:07 +01:00
gint64
nm_device_get_configured_mtu_from_connection_default (NMDevice *self,
const char *property_name)
{
gs_free char *str = NULL;
str = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA, property_name, self);
return _nm_utils_ascii_str_to_int64 (str, 10, 0, G_MAXUINT32, -1);
}
device: refactor setting user-configured MTU during config commit Instead of overwriting ip4_config_pre_commit(), add a new function get_mtu(). This also adds a default value in case there is no user-configuration. This will allow us later to reset a default MTU based on the device type.
2017-01-14 17:04:17 +01:00
guint32
nm_device_get_configured_mtu_for_wired (NMDevice *self, gboolean *out_is_user_config)
{
NMConnection *connection;
NMSettingWired *setting;
device: make the MTU globally configurable via connection-defaults This allows a user to restore the previous behavior where NetworkManager would not reconfigure the MTU during device activation, if no MTU is available (commit "22e8af6 device: set a per-device default MTU on activation"). Well, not exactly. The previous behavior was to use per-connection configuration, then DHCP provided value, or finally leave the MTU unspecified. Now, we prefer a per-connection configuration, followed by a global connection default. If "ethernet.mtu=0", the MTU is left unspecified. In absense of a global connection default, the value from DHCP is used or finally a per-device-type default. That is effectively 1500 for most types, except for infiniband where the MTU is still left unspecified.
2017-01-17 13:11:07 +01:00
gint64 mtu_default;
device: refactor setting user-configured MTU during config commit Instead of overwriting ip4_config_pre_commit(), add a new function get_mtu(). This also adds a default value in case there is no user-configuration. This will allow us later to reset a default MTU based on the device type.
2017-01-14 17:04:17 +01:00
guint32 mtu;
nm_assert (NM_IS_DEVICE (self));
nm_assert (out_is_user_config);
connection = nm_device_get_applied_connection (self);
if (!connection)
g_return_val_if_reached (0);
setting = nm_connection_get_setting_wired (connection);
if (setting) {
mtu = nm_setting_wired_get_mtu (setting);
if (mtu) {
*out_is_user_config = TRUE;
return mtu;
}
}
device: make the MTU globally configurable via connection-defaults This allows a user to restore the previous behavior where NetworkManager would not reconfigure the MTU during device activation, if no MTU is available (commit "22e8af6 device: set a per-device default MTU on activation"). Well, not exactly. The previous behavior was to use per-connection configuration, then DHCP provided value, or finally leave the MTU unspecified. Now, we prefer a per-connection configuration, followed by a global connection default. If "ethernet.mtu=0", the MTU is left unspecified. In absense of a global connection default, the value from DHCP is used or finally a per-device-type default. That is effectively 1500 for most types, except for infiniband where the MTU is still left unspecified.
2017-01-17 13:11:07 +01:00
mtu_default = nm_device_get_configured_mtu_from_connection_default (self, "ethernet.mtu");
if (mtu_default >= 0) {
*out_is_user_config = TRUE;
return (guint32) mtu_default;
}
device: refactor setting user-configured MTU during config commit Instead of overwriting ip4_config_pre_commit(), add a new function get_mtu(). This also adds a default value in case there is no user-configuration. This will allow us later to reset a default MTU based on the device type.
2017-01-14 17:04:17 +01:00
*out_is_user_config = FALSE;
device: don't set MTU of device unless explicitly configured Since commit 2b51d3967 "device: merge branch 'th/device-mtu-bgo777251'", we always set the MTU for certain device types during activation. Even if the MTU is neither specified via the connection nor other means, like DHCP. Revert that change. On activation, if nothing explicitly configures the MTU, leave it unchanged. This is like what we do with ethernet's cloned-mac-address, which has a default value "preserve". So, as last resort the default value for MTU is now 0 (don't change), instead of depending on the device type. Note that you also can override the default value in global configuration via NetworkManager.conf. This behavior makes sense, because whenever NM actively resets the MTU, it remembers the previous value and restores it when deactivating the connection. That wasn't implemented before 2b51d3967, and the MTU would depend on which connection was previously active. That is no longer an issue as the MTU gets reset when deactivating. https://bugzilla.redhat.com/show_bug.cgi?id=1460760
2017-06-13 12:26:51 +02:00
return 0;
device: refactor setting user-configured MTU during config commit Instead of overwriting ip4_config_pre_commit(), add a new function get_mtu(). This also adds a default value in case there is no user-configuration. This will allow us later to reset a default MTU based on the device type.
2017-01-14 17:04:17 +01:00
}
/*****************************************************************************/
device: set MTU property of device in new _set_mtu() function
2017-10-13 13:11:11 +02:00
static void
_set_mtu (NMDevice *self, guint32 mtu)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->mtu == mtu)
return;
priv->mtu = mtu;
_notify (self, PROP_MTU);
device: reset MTU when slave's MTU changes
2017-10-18 19:01:50 +02:00
if (priv->master) {
/* changing the MTU of a slave, might require the master to reset
* it's MTU. Note that the master usually cannot set a MTU larger
* then the slave's. Hence, when the slave increases the MTU,
* master might want to retry setting the MTU. */
nm_device_commit_mtu (priv->master);
}
device: set MTU property of device in new _set_mtu() function
2017-10-13 13:11:11 +02:00
}
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
static void
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
_commit_mtu (NMDevice *self, const NMIP4Config *config)
device: properly handle MTU for devices with @iface != @ip_iface When the device has an IP interface different from the main one, we previously took the MTU saved in priv->mtu (which is the MTU initially set on the underlying interface) and applied it to the IP interface. This is wrong as it forces the two MTUs to be equal and breaks connectivity for devices with encapsulation (as PPP). Instead, track the two MTUs in different variables. https://bugzilla.redhat.com/show_bug.cgi?id=1385198
2016-10-19 15:55:01 +02:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
guint32 ip6_mtu, ip6_mtu_orig;
guint32 mtu_desired, mtu_desired_orig;
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
guint32 mtu_plat;
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
struct {
gboolean initialized;
guint32 value;
device: add an initializer Basically to silence gcc that is not smart enough to understand how does .initialized and .value relate. src/devices/nm-device.c: In function '_commit_mtu': src/devices/nm-device.c:6754:15: error: 'ip6_mtu_sysctl.value' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (ip6_mtu && ip6_mtu != _IP6_MTU_SYS ()) { ^ (cherry picked from commit 7ce805d49d25fec60b50b4c53459df835512d279)
2017-01-17 16:16:46 +01:00
} ip6_mtu_sysctl = { 0, };
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
int ifindex;
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
char sbuf[64], sbuf1[64], sbuf2[64];
device: properly handle MTU for devices with @iface != @ip_iface When the device has an IP interface different from the main one, we previously took the MTU saved in priv->mtu (which is the MTU initially set on the underlying interface) and applied it to the IP interface. This is wrong as it forces the two MTUs to be equal and breaks connectivity for devices with encapsulation (as PPP). Instead, track the two MTUs in different variables. https://bugzilla.redhat.com/show_bug.cgi?id=1385198
2016-10-19 15:55:01 +02:00
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
ifindex = nm_device_get_ip_ifindex (self);
if (ifindex <= 0)
return;
device: properly handle MTU for devices with @iface != @ip_iface When the device has an IP interface different from the main one, we previously took the MTU saved in priv->mtu (which is the MTU initially set on the underlying interface) and applied it to the IP interface. This is wrong as it forces the two MTUs to be equal and breaks connectivity for devices with encapsulation (as PPP). Instead, track the two MTUs in different variables. https://bugzilla.redhat.com/show_bug.cgi?id=1385198
2016-10-19 15:55:01 +02:00
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (nm_device_sys_iface_state_is_external_or_assume (self)) {
device: reset MTU when VLAN's parent device changes MTU Kernel does not allow setting the MTU of a VLAN larger then the MTU of the underlying device. Hence, we might initially fail to set a large MTU of the VLAN, but we have to retry when the MTU of the parent changes. https://bugzilla.redhat.com/show_bug.cgi?id=1414901
2017-10-12 19:36:09 +02:00
/* for assumed connections we don't tamper with the MTU. */
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
return;
}
{
gboolean mtu_is_user_config = FALSE;
guint32 mtu = 0;
device: set a per-device default MTU on activation In absence of an explicit MTU (either via user configuration, PPP or DHCP), set a default MTU on activation that depends on the device type. We only want to do that on the very first call to _commit_mtu(). Later calls (for example in response to new DHCP leases) skip over this step. This means, on activation the MTU will always be reset to a sensible value instead of preserving whatever was left from a previous configuration. This does not cover setting the MTU from the VPN plugin :(
2017-01-16 12:18:51 +01:00
/* preferably, get the MTU from explict user-configuration.
* Only if that fails, look at the current @config (which contains
* MTUs from DHCP/PPP) or maybe fallback to a device-specific MTU. */
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
if (NM_DEVICE_GET_CLASS (self)->get_configured_mtu)
mtu = NM_DEVICE_GET_CLASS (self)->get_configured_mtu (self, &mtu_is_user_config);
device: make the MTU globally configurable via connection-defaults This allows a user to restore the previous behavior where NetworkManager would not reconfigure the MTU during device activation, if no MTU is available (commit "22e8af6 device: set a per-device default MTU on activation"). Well, not exactly. The previous behavior was to use per-connection configuration, then DHCP provided value, or finally leave the MTU unspecified. Now, we prefer a per-connection configuration, followed by a global connection default. If "ethernet.mtu=0", the MTU is left unspecified. In absense of a global connection default, the value from DHCP is used or finally a per-device-type default. That is effectively 1500 for most types, except for infiniband where the MTU is still left unspecified.
2017-01-17 13:11:07 +01:00
if (mtu_is_user_config)
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
mtu_desired = mtu;
else {
if (config)
mtu_desired = nm_ip4_config_get_mtu (config);
else
mtu_desired = 0;
device: set a per-device default MTU on activation In absence of an explicit MTU (either via user configuration, PPP or DHCP), set a default MTU on activation that depends on the device type. We only want to do that on the very first call to _commit_mtu(). Later calls (for example in response to new DHCP leases) skip over this step. This means, on activation the MTU will always be reset to a sensible value instead of preserving whatever was left from a previous configuration. This does not cover setting the MTU from the VPN plugin :(
2017-01-16 12:18:51 +01:00
if (!mtu_desired && !priv->mtu_initialized) {
/* there is no MTU specified, and this is the first commit of the MTU.
* Reset a per-device MTU default, as returned from get_configured_mtu().
*
* The device might choose not to return a default MTU via get_configured_mtu()
* to suppress this behavior. */
mtu_desired = mtu;
}
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
}
}
device: enforce a link MTU of at least 1280 for connections with IPv6
2017-01-16 14:58:11 +01:00
if (mtu_desired && mtu_desired < 1280) {
NMSettingIPConfig *s_ip6;
s_ip6 = (NMSettingIPConfig *) nm_device_get_applied_setting (self, NM_TYPE_SETTING_IP6_CONFIG);
device: fix setting minimal MTU to 1280 for IPv6 Fixes: 665e3980221c04c327b3c165f4a3f82fe470e87e (cherry picked from commit ec66135a40efa2326494af6e99f203654a302a69)
2017-01-24 16:28:04 +01:00
if ( s_ip6
&& !NM_IN_STRSET (nm_setting_ip_config_get_method (s_ip6),
NM_SETTING_IP6_CONFIG_METHOD_IGNORE)) {
device: enforce a link MTU of at least 1280 for connections with IPv6
2017-01-16 14:58:11 +01:00
/* the interface has IPv6 enabled. The MTU with IPv6 cannot be smaller
* then 1280.
*
* For slave-devices (that don't have @s_ip6 we) don't do this fixup because
* it's anyway an unsolved problem when the slave configures a conflicting
* MTU. */
mtu_desired = 1280;
}
}
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
ip6_mtu = priv->ip6_mtu;
device: set a per-device default MTU on activation In absence of an explicit MTU (either via user configuration, PPP or DHCP), set a default MTU on activation that depends on the device type. We only want to do that on the very first call to _commit_mtu(). Later calls (for example in response to new DHCP leases) skip over this step. This means, on activation the MTU will always be reset to a sensible value instead of preserving whatever was left from a previous configuration. This does not cover setting the MTU from the VPN plugin :(
2017-01-16 12:18:51 +01:00
if (!ip6_mtu && !priv->mtu_initialized) {
/* initially, if the IPv6 MTU is not specified, grow it as large as the
* link MTU @mtu_desired. Only exception is, if @mtu_desired is so small
* to disable IPv6. */
if (mtu_desired >= 1280)
ip6_mtu = mtu_desired;
}
priv->mtu_initialized = TRUE;
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
if (!ip6_mtu && !mtu_desired)
return;
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
mtu_desired_orig = mtu_desired;
ip6_mtu_orig = ip6_mtu;
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
mtu_plat = nm_platform_link_get_mtu (nm_device_get_platform (self), ifindex);
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
if (ip6_mtu) {
ip6_mtu = NM_MAX (1280, ip6_mtu);
nm-device: move device MTU setting from IP4Config to NMDevice Just a refactoring, no functional change. This will make it easier to coordinate the device MTU with IPv6 MTU.
2015-02-25 15:21:48 +01:00
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
if (!mtu_desired)
mtu_desired = mtu_plat;
nm-device: set ipv6 mtu at config commit time Just a refactoring, doesn't make any actual difference. It is consistent with IPv4 and will make it easier to implement a policy to recover from incorrect MTUs settings.
2015-02-25 14:49:34 +01:00
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
if (mtu_desired) {
mtu_desired = NM_MAX (1280, mtu_desired);
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
if (mtu_desired < ip6_mtu)
ip6_mtu = mtu_desired;
}
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
}
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
_LOGT (LOGD_DEVICE, "mtu: device-mtu: %u%s, ipv6-mtu: %u%s, ifindex: %d",
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
(guint) mtu_desired,
mtu_desired == mtu_desired_orig ? "" : nm_sprintf_buf (sbuf1, " (was %u)", (guint) mtu_desired_orig),
(guint) ip6_mtu,
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
ip6_mtu == ip6_mtu_orig ? "" : nm_sprintf_buf (sbuf2, " (was %u)", (guint) ip6_mtu_orig),
ifindex);
#define _IP6_MTU_SYS() \
({ \
if (!ip6_mtu_sysctl.initialized) { \
ip6_mtu_sysctl.value = nm_device_ipv6_sysctl_get_uint32 (self, "mtu", 0); \
ip6_mtu_sysctl.initialized = TRUE; \
} \
ip6_mtu_sysctl.value; \
})
if ( (mtu_desired && mtu_desired != mtu_plat)
|| (ip6_mtu && ip6_mtu != _IP6_MTU_SYS ())) {
device: show better logging message when setting MTU fails Setting the MTU might fail when the underlying device's MTU is not set. Detect that case, and log a better warning message. Unfortunately, it's tricky to detect whether this is a complete failure, or whether we will later try again to change the MTU. So, we log a failure, altough later we might fix it. It would be better not to warn about non-errors.
2017-10-23 15:41:07 +02:00
gboolean anticipated_failure = FALSE;
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
if (!priv->mtu_initial && !priv->ip6_mtu_initial) {
/* before touching any of the MTU paramters, record the
* original setting to restore on deactivation. */
priv->mtu_initial = mtu_plat;
priv->ip6_mtu_initial = _IP6_MTU_SYS ();
}
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
if (mtu_desired && mtu_desired != mtu_plat) {
device: show better logging message when setting MTU fails Setting the MTU might fail when the underlying device's MTU is not set. Detect that case, and log a better warning message. Unfortunately, it's tricky to detect whether this is a complete failure, or whether we will later try again to change the MTU. So, we log a failure, altough later we might fix it. It would be better not to warn about non-errors.
2017-10-23 15:41:07 +02:00
if (nm_platform_link_set_mtu (nm_device_get_platform (self), ifindex, mtu_desired) == NM_PLATFORM_ERROR_CANT_SET_MTU) {
anticipated_failure = TRUE;
_LOGW (LOGD_DEVICE, "mtu: failure to set MTU. %s",
NM_IS_DEVICE_VLAN (self)
? "Is the parent's MTU size large enough?"
: (!c_list_is_empty (&priv->slaves)
? "Are the MTU sizes of the slaves large enough?"
: "Did you configure the MTU correctly?"));
}
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
priv->carrier_wait_until_ms = nm_utils_get_monotonic_timestamp_ms () + CARRIER_WAIT_TIME_AFTER_MTU_MS;
}
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
if (ip6_mtu && ip6_mtu != _IP6_MTU_SYS ()) {
device: show better logging message when setting MTU fails Setting the MTU might fail when the underlying device's MTU is not set. Detect that case, and log a better warning message. Unfortunately, it's tricky to detect whether this is a complete failure, or whether we will later try again to change the MTU. So, we log a failure, altough later we might fix it. It would be better not to warn about non-errors.
2017-10-23 15:41:07 +02:00
if (!nm_device_ipv6_sysctl_set (self, "mtu",
nm_sprintf_buf (sbuf, "%u", (unsigned) ip6_mtu))) {
int errsv = errno;
_NMLOG (anticipated_failure && errsv == EINVAL ? LOGL_DEBUG : LOGL_WARN,
LOGD_DEVICE,
"mtu: failure to set IPv6 MTU%s",
anticipated_failure && errsv == EINVAL
? ": Is the underlying MTU value successfully set?"
: "");
}
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
priv->carrier_wait_until_ms = nm_utils_get_monotonic_timestamp_ms () + CARRIER_WAIT_TIME_AFTER_MTU_MS;
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
}
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
}
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
#undef _IP6_MTU_SYS
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
}
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
device: reset MTU when VLAN's parent device changes MTU Kernel does not allow setting the MTU of a VLAN larger then the MTU of the underlying device. Hence, we might initially fail to set a large MTU of the VLAN, but we have to retry when the MTU of the parent changes. https://bugzilla.redhat.com/show_bug.cgi?id=1414901
2017-10-12 19:36:09 +02:00
void
nm_device_commit_mtu (NMDevice *self)
{
NMDeviceState state;
g_return_if_fail (NM_IS_DEVICE (self));
state = nm_device_get_state (self);
if ( state >= NM_DEVICE_STATE_CONFIG
&& state < NM_DEVICE_STATE_DEACTIVATING) {
_LOGT (LOGD_DEVICE, "mtu: commit-mtu...");
_commit_mtu (self, NM_DEVICE_GET_PRIVATE (self)->ip4_config);
} else
_LOGT (LOGD_DEVICE, "mtu: commit-mtu... skip due to state %s", nm_device_state_to_str (state));
}
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
static void
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
ndisc_config_changed (NMNDisc *ndisc, const NMNDiscData *rdata, guint changed_int, NMDevice *self)
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
{
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
NMNDiscConfigMap changed = changed_int;
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: cleanup setting ifa_flags in ndisc_config_changed() Some refactoring and one change: If we don't have system-support, don't set IFA_F_MANAGETEMPADDR.
2017-08-16 14:50:01 +02:00
guint i;
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
device: use internal router discovery implementation
2013-05-30 16:53:23 +02:00
g_return_if_fail (priv->act_request);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
core: pass ifindex as parameter to nm_ip6_config_new()
2015-02-27 16:49:42 +01:00
if (!priv->ac_ip6_config)
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
priv->ac_ip6_config = _ip6_config_new (self);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (changed & NM_NDISC_CONFIG_ADDRESSES) {
core: cleanup setting ifa_flags in ndisc_config_changed() Some refactoring and one change: If we don't have system-support, don't set IFA_F_MANAGETEMPADDR.
2017-08-16 14:50:01 +02:00
guint8 plen;
guint32 ifa_flags;
/* Check, whether kernel is recent enough to help user space handling RA.
* If it's not supported, we have no ipv6-privacy and must add autoconf
* addresses as /128. The reason for the /128 is to prevent the kernel
* from adding a prefix route for this address. */
ifa_flags = 0;
platform: refactor detecting kernel support We are going to add another parameter to check. Instead of adding multiple virtual functions, add a NMPlatformKernelSupportFlags flags enum.
2017-10-10 18:20:05 +02:00
if (nm_platform_check_kernel_support (nm_device_get_platform (self),
NM_PLATFORM_KERNEL_SUPPORT_EXTENDED_IFA_FLAGS)) {
core: cleanup setting ifa_flags in ndisc_config_changed() Some refactoring and one change: If we don't have system-support, don't set IFA_F_MANAGETEMPADDR.
2017-08-16 14:50:01 +02:00
ifa_flags |= IFA_F_NOPREFIXROUTE;
if (NM_IN_SET (priv->ndisc_use_tempaddr, NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_TEMP_ADDR,
NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_PUBLIC_ADDR))
ifa_flags |= IFA_F_MANAGETEMPADDR;
plen = 64;
} else
plen = 128;
core: move setting NDisc addresses/routes to NMIP6Config Add an utility function for resetting addresses/routes of NMIP6Config from NMNDisc data. For one, this de-duplicates code in device and nm-iface-helper. Also, we no longer first reset (delete) all addresses and add them anew. Instead, we first mark all entries as dirty for deletion, merge (append) the new entires, and delete the remaining dirty entires. This saves a extra work, in the expected case where NMIP6Config already contains several of the new entries.
2017-08-16 13:57:01 +02:00
nm_ip6_config_reset_addresses_ndisc (priv->ac_ip6_config,
rdata->addresses,
rdata->addresses_n,
core: cleanup setting ifa_flags in ndisc_config_changed() Some refactoring and one change: If we don't have system-support, don't set IFA_F_MANAGETEMPADDR.
2017-08-16 14:50:01 +02:00
plen,
core: move setting NDisc addresses/routes to NMIP6Config Add an utility function for resetting addresses/routes of NMIP6Config from NMNDisc data. For one, this de-duplicates code in device and nm-iface-helper. Also, we no longer first reset (delete) all addresses and add them anew. Instead, we first mark all entries as dirty for deletion, merge (append) the new entires, and delete the remaining dirty entires. This saves a extra work, in the expected case where NMIP6Config already contains several of the new entries.
2017-08-16 13:57:01 +02:00
ifa_flags);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
}
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (NM_FLAGS_ANY (changed, NM_NDISC_CONFIG_ROUTES
| NM_NDISC_CONFIG_GATEWAYS)) {
core: move setting NDisc addresses/routes to NMIP6Config Add an utility function for resetting addresses/routes of NMIP6Config from NMNDisc data. For one, this de-duplicates code in device and nm-iface-helper. Also, we no longer first reset (delete) all addresses and add them anew. Instead, we first mark all entries as dirty for deletion, merge (append) the new entires, and delete the remaining dirty entires. This saves a extra work, in the expected case where NMIP6Config already contains several of the new entries.
2017-08-16 13:57:01 +02:00
nm_ip6_config_reset_routes_ndisc (priv->ac_ip6_config,
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
rdata->gateways,
rdata->gateways_n,
core: move setting NDisc addresses/routes to NMIP6Config Add an utility function for resetting addresses/routes of NMIP6Config from NMNDisc data. For one, this de-duplicates code in device and nm-iface-helper. Also, we no longer first reset (delete) all addresses and add them anew. Instead, we first mark all entries as dirty for deletion, merge (append) the new entires, and delete the remaining dirty entires. This saves a extra work, in the expected case where NMIP6Config already contains several of the new entries.
2017-08-16 13:57:01 +02:00
rdata->routes,
rdata->routes_n,
core: use ipv6.route-table setting for other IPv6 routes Including device-routes, default-route, SLAAC.
2017-09-28 18:48:39 +02:00
nm_device_get_route_table (self, AF_INET6, TRUE),
core: use router preference for IPv6 routes For routes and the default-route from NDisc, set the router preference RTA_PREF. Also, previously, we would only configure one IPv6 default-route. That by itself was not really a problem, as long as NetworkManager would always make sure that it configured the route to the ~best~ router. Actually, NM should have done that already. It keeps the list of gateways sorted, and prefers them according to their preference. But maybe it didn't, so we have bug rh#1445417 (??). Change that by configuring a default-route for all gateways, with appropriate router prefrence. In case, kernel doesn't support RTA_PREF yet, only configure all routes that share the same maxiumum preference. https://bugzilla.redhat.com/show_bug.cgi?id=1445417
2017-10-09 10:58:47 +02:00
nm_device_get_route_metric (self, AF_INET6),
nm_platform_check_kernel_support (nm_device_get_platform (self),
NM_PLATFORM_KERNEL_SUPPORT_RTA_PREF));
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
}
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (changed & NM_NDISC_CONFIG_DNS_SERVERS) {
/* Rebuild DNS server list from neighbor discovery cache. */
device: use internal router discovery implementation
2013-05-30 16:53:23 +02:00
nm_ip6_config_reset_nameservers (priv->ac_ip6_config);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
rdisc: hide internal fields from NMRDisc API Hide the mutable fields that were exposed to the user of the NMRDisc API. Instead, only expose a constant NMRDiscData structure.
2016-07-07 13:25:38 +02:00
for (i = 0; i < rdata->dns_servers_n; i++)
nm_ip6_config_add_nameserver (priv->ac_ip6_config, &rdata->dns_servers[i].address);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
}
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (changed & NM_NDISC_CONFIG_DNS_DOMAINS) {
/* Rebuild domain list from neighbor discovery cache. */
device: the domain list from DNSSL is in fact a search list
2016-11-01 13:33:32 +01:00
nm_ip6_config_reset_searches (priv->ac_ip6_config);
rdisc: clear domain list when updating from RA Appears to be a simple oversight. If the IPv6 router changes the domain list, old domains could stick around.
2013-12-19 10:58:46 -06:00
rdisc: hide internal fields from NMRDisc API Hide the mutable fields that were exposed to the user of the NMRDisc API. Instead, only expose a constant NMRDiscData structure.
2016-07-07 13:25:38 +02:00
for (i = 0; i < rdata->dns_domains_n; i++)
device: the domain list from DNSSL is in fact a search list
2016-11-01 13:33:32 +01:00
nm_ip6_config_add_search (priv->ac_ip6_config, rdata->dns_domains[i].domain);
device: use internal router discovery implementation
2013-05-30 16:53:23 +02:00
}
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (changed & NM_NDISC_CONFIG_DHCP_LEVEL) {
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
dhcp6_cleanup (self, CLEANUP_TYPE_DECONFIGURE, TRUE);
device: use internal router discovery implementation
2013-05-30 16:53:23 +02:00
rdisc: hide internal fields from NMRDisc API Hide the mutable fields that were exposed to the user of the NMRDisc API. Instead, only expose a constant NMRDiscData structure.
2016-07-07 13:25:38 +02:00
priv->dhcp6.mode = rdata->dhcp_level;
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (priv->dhcp6.mode != NM_NDISC_DHCP_LEVEL_NONE) {
device/logging: downgrade log level of "Activation: Stage x of 5" messages Only downgrade the <info> levels to <debug>. Leave warnings unchanged. https://bugzilla.redhat.com/show_bug.cgi?id=1212196
2015-04-17 15:56:04 +02:00
_LOGD (LOGD_DEVICE | LOGD_DHCP6,
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
"Activation: Stage 3 of 5 (IP Configure Start) starting DHCPv6"
" as requested by IPv6 router...");
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
if (!dhcp6_start (self, FALSE)) {
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (priv->dhcp6.mode == NM_NDISC_DHCP_LEVEL_MANAGED) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_DHCP_START_FAILED);
device: apply the iv6 configuration as soon as we get the RA With DHCPv6 it might be quite some time (we may even time out) until we get all the information to finish activation, but we already have the addresses and routes.
2016-01-14 20:42:01 +01:00
return;
}
device: use internal router discovery implementation
2013-05-30 16:53:23 +02:00
}
}
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
}
device: use internal router discovery implementation
2013-05-30 16:53:23 +02:00
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (changed & NM_NDISC_CONFIG_HOP_LIMIT)
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_sysctl_set_ip6_hop_limit_safe (nm_device_get_platform (self), nm_device_get_ip_iface (self), rdata->hop_limit);
devices: propagate the hop limit from an IPv6 RA to the kernel config If we set accept_ra_defrtr=0 then the kernel will ignore the "hop limit" too. So parse it out of the RA and set it manually.
2014-02-21 17:21:59 -05:00
device: refactor handling of MTU in device The field priv->mtu should contain what is actually configured on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU property. That shall be handled distinct from what we want to configure as MTU on the device. Refactor the handling of MTU with a new functoin _set_mtu() which looks at the desired paramters and compares it with what is configured (in platform and sysctl). Then it makes a decision what to configure.
2017-01-13 18:40:50 +01:00
if (changed & NM_NDISC_CONFIG_MTU) {
if (priv->ip6_mtu != rdata->mtu) {
_LOGD (LOGD_DEVICE, "mtu: set IPv6 MTU to %u", (guint) rdata->mtu);
priv->ip6_mtu = rdata->mtu;
}
}
rdisc,device: set MTU if an appropriate option is present in a RA https://bugzilla.gnome.org/show_bug.cgi?id=738104 Reported-by: Charles R. Anderson <cra@wpi.edu>
2014-10-09 12:06:53 +02:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_activate_schedule_ip6_config_result (self);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
}
rdisc: add RA wait timeout Add an advisory timeout when waiting for router advertisements so we can fail IPv6 addressing attempts when no router advertisement has been received.
2014-08-13 09:40:08 -05:00
static void
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
ndisc_ra_timeout (NMNDisc *ndisc, NMDevice *self)
rdisc: add RA wait timeout Add an advisory timeout when waiting for router advertisements so we can fail IPv6 addressing attempts when no router advertisement has been received.
2014-08-13 09:40:08 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
/* We don't want to stop listening for router advertisements completely,
* but instead let device activation continue activating. If an RA
* shows up later, we'll use it as long as the device is not disconnected.
*/
_LOGD (LOGD_IP6, "timed out waiting for IPv6 router advertisement");
core: complete IPv6 even if RA times out when there are manual/external addresses Even if we never receive an RA, if there are manually-specified or external addresses, consider IPv6 to complete successfully. No reason to fail IPv6 if we have IP configuration already, but RA doesn't respond. If RA shows up again, we're still listening for it and will apply the config at that time.
2014-08-13 14:44:22 -05:00
if (priv->ip6_state == IP_CONF) {
/* If RA is our only source of addressing information and we don't
* ever receive one, then time out IPv6. But if there is other
* IPv6 configuration, like manual IPv6 addresses or external IPv6
* config, consider that sufficient for IPv6 success.
*/
device: check nm_ip6_config_get_address_first_nontentative() argument Since commit 9ff161b2a1b0 ("device: move have_ip6_address() to nm_ip6_config_get_address_first_nontentative()") the IP configuration argument of nm_ip6_config_get_address_first_nontentative() must be non-NULL. Add checks where needed. Fixes: 9ff161b2a1b0d4a63f91d326050ae1b8906b7b1b
2016-02-03 09:05:25 +01:00
if ( priv->ip6_config
&& nm_ip6_config_get_address_first_nontentative (priv->ip6_config, FALSE))
core: complete IPv6 even if RA times out when there are manual/external addresses Even if we never receive an RA, if there are manually-specified or external addresses, consider IPv6 to complete successfully. No reason to fail IPv6 if we have IP configuration already, but RA doesn't respond. If RA shows up again, we're still listening for it and will apply the config at that time.
2014-08-13 14:44:22 -05:00
nm_device_activate_schedule_ip6_config_result (self);
else
nm_device_activate_schedule_ip6_config_timeout (self);
}
rdisc: add RA wait timeout Add an advisory timeout when waiting for router advertisements so we can fail IPv6 addressing attempts when no router advertisement has been received.
2014-08-13 09:40:08 -05:00
}
core: fail IPv6 router discovery if IID cannot be generated If the IID cannot be generated, the IPv6 address resulting from the combination of an advertised prefix and 64-bits of zero is both wrong and quite likely to clash with some other machine on the network that doesn't implement IPv6 quite right either. Require an valid interface identifier. If NetworkManager doesn't know how to generate one, then we should fix NM to do so.
2014-07-22 16:24:07 -05:00
static gboolean
trivial: move addrconf6_start_with_link_ready() above caller
2014-07-22 16:20:36 -05:00
addrconf6_start_with_link_ready (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMUtilsIPv6IfaceId iid;
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
g_assert (priv->ndisc);
trivial: move addrconf6_start_with_link_ready() above caller
2014-07-22 16:20:36 -05:00
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
if (nm_device_get_ip_iface_identifier (self, &iid, FALSE)) {
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
_LOGD (LOGD_IP6, "addrconf6: using the device EUI-64 identifier");
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
nm_ndisc_set_iid (priv->ndisc, iid);
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
} else {
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
/* Don't abort the addrconf at this point -- if ndisc needs the iid
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
* it will notice this itself. */
_LOGI (LOGD_IP6, "addrconf6: no interface identifier; IPv6 adddress creation may fail");
core: fail IPv6 router discovery if IID cannot be generated If the IID cannot be generated, the IPv6 address resulting from the combination of an advertised prefix and 64-bits of zero is both wrong and quite likely to clash with some other machine on the network that doesn't implement IPv6 quite right either. Require an valid interface identifier. If NetworkManager doesn't know how to generate one, then we should fix NM to do so.
2014-07-22 16:24:07 -05:00
}
trivial: move addrconf6_start_with_link_ready() above caller
2014-07-22 16:20:36 -05:00
core: apply manual IPv6 configuration earlier when RA is also used (rh #1101809) Reporter left SLAAC enabled (because it's default and requires being explicitly turned off) and added manual IPv6 address. They expected that address to be assigned very soon after starting the connection, but it was not assigned. This happened because NM waits for RA before assigning any IPv6 configuration, including the manually specified addresses. In the reporters case, there was no IPv6 router on the network, so NM waited indefinitely for a router advertisement and never applied any IPv6 configuration. It seems reasonable to apply any IPv6 configuration we have available, when we have it. We already apply RA configuration before starting DHCP, and apply DHCP configuration if/when we get that.
2014-08-13 14:29:25 -05:00
/* Apply any manual configuration before starting RA */
device: reset @con_ip6_config on failure before RA If the commit of static connection parameters fails before starting RA, we should reset @con_ip6_config; otherwise any external update arriving before the commit of RA parameters will remove from @con_ip6_config all parameters not present externally, because in update_ip6_config() we do: /* This function was called upon external changes. Remove the configuration * (addresses,routes) that is no longer present externally from the internal * config. This way, we don't re-add addresses that were manually removed * by the user. */ if (priv->con_ip6_config) nm_ip6_config_intersect (priv->con_ip6_config, priv->ext_ip6_config); Instead if @con_ip6_config is cleared it will be rebuilt from the connection setting at the next commit. Fixes-test: @ipv6_preserve_cached_routes
2017-09-25 14:28:16 +02:00
if (!ip6_config_merge_and_apply (self, TRUE)) {
core: apply manual IPv6 configuration earlier when RA is also used (rh #1101809) Reporter left SLAAC enabled (because it's default and requires being explicitly turned off) and added manual IPv6 address. They expected that address to be assigned very soon after starting the connection, but it was not assigned. This happened because NM waits for RA before assigning any IPv6 configuration, including the manually specified addresses. In the reporters case, there was no IPv6 router on the network, so NM waited indefinitely for a router advertisement and never applied any IPv6 configuration. It seems reasonable to apply any IPv6 configuration we have available, when we have it. We already apply RA configuration before starting DHCP, and apply DHCP configuration if/when we get that.
2014-08-13 14:29:25 -05:00
_LOGW (LOGD_IP6, "failed to apply manual IPv6 configuration");
device: reset @con_ip6_config on failure before RA If the commit of static connection parameters fails before starting RA, we should reset @con_ip6_config; otherwise any external update arriving before the commit of RA parameters will remove from @con_ip6_config all parameters not present externally, because in update_ip6_config() we do: /* This function was called upon external changes. Remove the configuration * (addresses,routes) that is no longer present externally from the internal * config. This way, we don't re-add addresses that were manually removed * by the user. */ if (priv->con_ip6_config) nm_ip6_config_intersect (priv->con_ip6_config, priv->ext_ip6_config); Instead if @con_ip6_config is cleared it will be rebuilt from the connection setting at the next commit. Fixes-test: @ipv6_preserve_cached_routes
2017-09-25 14:28:16 +02:00
g_clear_object (&priv->con_ip6_config);
}
core: apply manual IPv6 configuration earlier when RA is also used (rh #1101809) Reporter left SLAAC enabled (because it's default and requires being explicitly turned off) and added manual IPv6 address. They expected that address to be assigned very soon after starting the connection, but it was not assigned. This happened because NM waits for RA before assigning any IPv6 configuration, including the manually specified addresses. In the reporters case, there was no IPv6 router on the network, so NM waited indefinitely for a router advertisement and never applied any IPv6 configuration. It seems reasonable to apply any IPv6 configuration we have available, when we have it. We already apply RA configuration before starting DHCP, and apply DHCP configuration if/when we get that.
2014-08-13 14:29:25 -05:00
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
/* XXX: These sysctls would probably be better set by the lndp ndisc itself. */
switch (nm_ndisc_get_node_type (priv->ndisc)) {
case NM_NDISC_NODE_TYPE_HOST:
/* Accepting prefixes from discovered routers. */
nm_device_ipv6_sysctl_set (self, "accept_ra", "1");
nm_device_ipv6_sysctl_set (self, "accept_ra_defrtr", "0");
nm_device_ipv6_sysctl_set (self, "accept_ra_pinfo", "0");
nm_device_ipv6_sysctl_set (self, "accept_ra_rtr_pref", "0");
break;
case NM_NDISC_NODE_TYPE_ROUTER:
/* We're the router. */
nm_device_ipv6_sysctl_set (self, "forwarding", "1");
nm_device_activate_schedule_ip6_config_result (self);
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
priv->needs_ip6_subnet = TRUE;
g_signal_emit (self, signals[IP6_SUBNET_NEEDED], 0);
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
break;
default:
g_assert_not_reached ();
}
trivial: move addrconf6_start_with_link_ready() above caller
2014-07-22 16:20:36 -05:00
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
priv->ndisc_changed_id = g_signal_connect (priv->ndisc,
ndisc: rename the config-changed signal The ndisc config can now be changed by NMDevice as well when the NDisc is in ROUTER mode. But what we're really interested in is when we receive a new one from the outside.
2016-11-09 17:21:41 +01:00
NM_NDISC_CONFIG_RECEIVED,
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
G_CALLBACK (ndisc_config_changed),
rdisc: add RA wait timeout Add an advisory timeout when waiting for router advertisements so we can fail IPv6 addressing attempts when no router advertisement has been received.
2014-08-13 09:40:08 -05:00
self);
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
priv->ndisc_timeout_id = g_signal_connect (priv->ndisc,
NM_NDISC_RA_TIMEOUT,
G_CALLBACK (ndisc_ra_timeout),
rdisc: add RA wait timeout Add an advisory timeout when waiting for router advertisements so we can fail IPv6 addressing attempts when no router advertisement has been received.
2014-08-13 09:40:08 -05:00
self);
core: Use tokenized identifiers when constructing an address We trigger a new solicitation upon seeing the new token. Kernel triggers one too, but that one is of no use to us, since the advertisement might arrive sooner than we learn about the token change.
2014-09-27 09:04:46 +02:00
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
ndisc_set_router_config (priv->ndisc, self);
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
nm_ndisc_start (priv->ndisc);
core: fail IPv6 router discovery if IID cannot be generated If the IID cannot be generated, the IPv6 address resulting from the combination of an advertised prefix and 64-bits of zero is both wrong and quite likely to clash with some other machine on the network that doesn't implement IPv6 quite right either. Require an valid interface identifier. If NetworkManager doesn't know how to generate one, then we should fix NM to do so.
2014-07-22 16:24:07 -05:00
return TRUE;
trivial: move addrconf6_start_with_link_ready() above caller
2014-07-22 16:20:36 -05:00
}
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
static NMNDiscNodeType
ndisc_node_type (NMDevice *self)
{
NMConnection *connection;
connection = nm_device_get_applied_connection (self);
g_assert (connection);
if (strcmp (nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG),
NM_SETTING_IP4_CONFIG_METHOD_SHARED) == 0)
return NM_NDISC_NODE_TYPE_ROUTER;
else
return NM_NDISC_NODE_TYPE_HOST;
}
core: fix return type of addrconf6_start() It returned a boolean and the caller expected a boolean, but the return type was NMActStageReturn.
2014-11-14 15:40:29 -06:00
static gboolean
core/rdisc: add support for IPv6 privacy Add support for ipv6-private addresses. This feature needs support from the kernel and libnl. If there is no system support, temporary addresses are not supported. Log a warning in this case. Depending on whether ipv6-privacy (use_tempaddr) is enabled, we add the address flag IFA_F_MANAGETEMPADDR and the kernel will add temporary addresses for us. https://bugzilla.gnome.org/show_bug.cgi?id=705170 https://bugzilla.redhat.com/show_bug.cgi?id=1003859 https://bugzilla.redhat.com/show_bug.cgi?id=1047139 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-03 17:03:35 +01:00
addrconf6_start (NMDevice *self, NMSettingIP6ConfigPrivacy use_tempaddr)
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
NMActStageReturn ret;
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
NMSettingIP6Config *s_ip6 = NULL;
rdisc: don't log error message when failing to create NDP socket Let the caller do that, he already logs an ERR level message. Just combine the messages.
2015-12-17 15:49:03 +01:00
GError *error = NULL;
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
NMUtilsStableType stable_type;
const char *stable_id;
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
g_assert (connection);
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
g_warn_if_fail (priv->ac_ip6_config == NULL);
if (priv->ac_ip6_config) {
g_object_unref (priv->ac_ip6_config);
priv->ac_ip6_config = NULL;
}
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
g_clear_pointer (&priv->rt6_temporary_not_available, g_hash_table_unref);
nm_clear_g_source (&priv->rt6_temporary_not_available_id);
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
s_ip6 = NM_SETTING_IP6_CONFIG (nm_connection_get_setting_ip6_config (connection));
g_assert (s_ip6);
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
stable_id = _get_stable_id (self, connection, &stable_type);
device: fix check in addrconf6_start() We check the return value of _get_stable_id(); when it is NULL priv->ndisc would stay NULL too and we would crash when dereferencing @error. Actually, _get_stable_id() can never return NULL, so replace the check with an assertion.
2017-05-08 14:42:40 +02:00
g_assert (stable_id);
priv->ndisc = nm_lndp_ndisc_new (nm_device_get_platform (self),
nm_device_get_ip_ifindex (self),
nm_device_get_ip_iface (self),
stable_type,
stable_id,
nm_setting_ip6_config_get_addr_gen_mode (s_ip6),
ndisc_node_type (self),
&error);
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if (!priv->ndisc) {
_LOGE (LOGD_IP6, "addrconf6: failed to start neighbor discovery: %s", error->message);
rdisc: don't log error message when failing to create NDP socket Let the caller do that, he already logs an ERR level message. Just combine the messages.
2015-12-17 15:49:03 +01:00
g_error_free (error);
device: use internal router discovery implementation
2013-05-30 16:53:23 +02:00
return FALSE;
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
}
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
priv->ndisc_use_tempaddr = use_tempaddr;
platform: create netlink messages directly without libnl-route-3 Instead of using libnl-route-3 library to serialize netlink messages, construct the netlink messages ourselves. This has several advantages: - Creating the netlink message ourself is actually more straight forward then having an intermediate layer between NM and the kernel. Now it is immediately clear, how a platform request translates to a netlink/kernel request. You can look at the kernel sources how a certain netlink attribute behaves, and then it's immediately clear how to set that (and vice versa). - Older libnl versions might have bugs or missing features for which we needed to workaround (often by offering a reduced/broken/untested functionality). Now we can get rid or workaround like _nl_has_capability(), check_support_libnl_extended_ifa_flags(), HAVE_LIBNL_INET6_TOKEN. Another example is a libnl bug when setting vlan ingress map which isn't even yet fixed in libnl upstream. - We no longer need libnl-route-3 at all and can drop that runtime requirement, saving some 400k. Constructing the messages ourselves also gives better performance because we don't have to create the intermediate libnl object. - In the future we will add more link-type support which is easier to support by basing directly on the plain kernel/netlink API, instead of requiring also libnl3 to expose this functionality. E.g. adding macvtap support: we already parsed macvtap properties ourselves because of missing libnl support. To *add* macvtap support, we also would have to do it ourself (or extend libnl).
2015-10-20 09:27:16 +02:00
if ( NM_IN_SET (use_tempaddr, NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_TEMP_ADDR, NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_PUBLIC_ADDR)
platform: refactor detecting kernel support We are going to add another parameter to check. Instead of adding multiple virtual functions, add a NMPlatformKernelSupportFlags flags enum.
2017-10-10 18:20:05 +02:00
&& !nm_platform_check_kernel_support (nm_device_get_platform (self),
NM_PLATFORM_KERNEL_SUPPORT_EXTENDED_IFA_FLAGS)) {
platform: create netlink messages directly without libnl-route-3 Instead of using libnl-route-3 library to serialize netlink messages, construct the netlink messages ourselves. This has several advantages: - Creating the netlink message ourself is actually more straight forward then having an intermediate layer between NM and the kernel. Now it is immediately clear, how a platform request translates to a netlink/kernel request. You can look at the kernel sources how a certain netlink attribute behaves, and then it's immediately clear how to set that (and vice versa). - Older libnl versions might have bugs or missing features for which we needed to workaround (often by offering a reduced/broken/untested functionality). Now we can get rid or workaround like _nl_has_capability(), check_support_libnl_extended_ifa_flags(), HAVE_LIBNL_INET6_TOKEN. Another example is a libnl bug when setting vlan ingress map which isn't even yet fixed in libnl upstream. - We no longer need libnl-route-3 at all and can drop that runtime requirement, saving some 400k. Constructing the messages ourselves also gives better performance because we don't have to create the intermediate libnl object. - In the future we will add more link-type support which is easier to support by basing directly on the plain kernel/netlink API, instead of requiring also libnl3 to expose this functionality. E.g. adding macvtap support: we already parsed macvtap properties ourselves because of missing libnl support. To *add* macvtap support, we also would have to do it ourself (or extend libnl).
2015-10-20 09:27:16 +02:00
_LOGW (LOGD_IP6, "The kernel does not support extended IFA_FLAGS needed by NM for "
"IPv6 private addresses. This feature is not available");
}
core/rdisc: add support for IPv6 privacy Add support for ipv6-private addresses. This feature needs support from the kernel and libnl. If there is no system support, temporary addresses are not supported. Log a warning in this case. Depending on whether ipv6-privacy (use_tempaddr) is enabled, we add the address flag IFA_F_MANAGETEMPADDR and the kernel will add temporary addresses for us. https://bugzilla.gnome.org/show_bug.cgi?id=705170 https://bugzilla.redhat.com/show_bug.cgi?id=1003859 https://bugzilla.redhat.com/show_bug.cgi?id=1047139 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-03 17:03:35 +01:00
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
if (!nm_setting_ip_config_get_may_fail (nm_connection_get_setting_ip6_config (connection)))
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_add_pending_action (self, NM_PENDING_ACTION_AUTOCONF6, TRUE);
core: wait with "startup complete" for both IPv4 and IPv6 dynamic configuration In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until both IPv4 and IPv6 are ready. This especially has an effect on nm-online/NetworkManager-wait-online.service, which blocks until configuration of both IPv4 and IPv6 is ready. We queue a pending_action when automatic configuration starts and remove it again, when we receive an address. Before, "startup complete" was reached when either one of the two IP protocols was configured. https://bugzilla.redhat.com/show_bug.cgi?id=1086906 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-14 17:57:56 +02:00
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
/* ensure link local is ready... */
ret = linklocal6_start (self);
core: fail IPv6 router discovery if IID cannot be generated If the IID cannot be generated, the IPv6 address resulting from the combination of an advertised prefix and 64-bits of zero is both wrong and quite likely to clash with some other machine on the network that doesn't implement IPv6 quite right either. Require an valid interface identifier. If NetworkManager doesn't know how to generate one, then we should fix NM to do so.
2014-07-22 16:24:07 -05:00
if (ret == NM_ACT_STAGE_RETURN_POSTPONE) {
/* success; wait for the LL address to show up */
return TRUE;
}
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
/* success; already have the LL address; kick off neighbor discovery */
device: remove unneeded activation-stage result NM_ACT_STAGE_RETURN_FINISH We can express FINISH by returning SUCCESS and not set out_config in act_stage3_ip4_config_start().
2016-08-29 15:33:33 +02:00
g_assert (ret == NM_ACT_STAGE_RETURN_SUCCESS);
core: fail IPv6 router discovery if IID cannot be generated If the IID cannot be generated, the IPv6 address resulting from the combination of an advertised prefix and 64-bits of zero is both wrong and quite likely to clash with some other machine on the network that doesn't implement IPv6 quite right either. Require an valid interface identifier. If NetworkManager doesn't know how to generate one, then we should fix NM to do so.
2014-07-22 16:24:07 -05:00
return addrconf6_start_with_link_ready (self);
core: wait for IPv6 link local address with method 'auto' and 'link-local' (bgo#707155) With the methods 'auto' and 'link-local' we check now, that the device has a usable IPv6 LL address configured (after DAD, no longer tentative). We wait for up to 5 seconds, for a suitable LL address to appear. Currently, if the address does not get ready, we don't create one and IPv6 configuration fails. This is relevant for the methods 'link-local' and 'auto'. In the latter case, because we cannot send router solitations without link local address. https://bugzilla.gnome.org/show_bug.cgi?id=707155 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 22:59:43 +01:00
}
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
static void
addrconf6_cleanup (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
nm_clear_g_signal_handler (priv->ndisc, &priv->ndisc_changed_id);
nm_clear_g_signal_handler (priv->ndisc, &priv->ndisc_timeout_id);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_remove_pending_action (self, NM_PENDING_ACTION_AUTOCONF6, FALSE);
core: wait with "startup complete" for both IPv4 and IPv6 dynamic configuration In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until both IPv4 and IPv6 are ready. This especially has an effect on nm-online/NetworkManager-wait-online.service, which blocks until configuration of both IPv4 and IPv6 is ready. We queue a pending_action when automatic configuration starts and remove it again, when we receive an address. Before, "startup complete" was reached when either one of the two IP protocols was configured. https://bugzilla.redhat.com/show_bug.cgi?id=1086906 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-14 17:57:56 +02:00
device: use internal router discovery implementation
2013-05-30 16:53:23 +02:00
g_clear_object (&priv->ac_ip6_config);
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
g_clear_pointer (&priv->rt6_temporary_not_available, g_hash_table_unref);
nm_clear_g_source (&priv->rt6_temporary_not_available_id);
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
g_clear_object (&priv->ndisc);
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: move some more code around No functional changes.
2011-10-07 11:53:09 -05:00
trivial: re-organize IPv6 /proc property util functions
2014-05-20 15:17:13 -05:00
static const char *ip6_properties_to_save[] = {
"accept_ra",
"accept_ra_defrtr",
"accept_ra_pinfo",
"accept_ra_rtr_pref",
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
"forwarding",
trivial: re-organize IPv6 /proc property util functions
2014-05-20 15:17:13 -05:00
"disable_ipv6",
"hop_limit",
"use_tempaddr",
};
static void
save_ip6_properties (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
const char *ifname = nm_device_get_ip_iface (self);
char *value;
int i;
g_hash_table_remove_all (priv->ip6_saved_properties);
device: avoid touching sysctls for devices without platform link Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to cunstruct sysctl paths and it is way less tolerant towards using something that is not an interface name in the path. It's always been incorrect to assume the ifname is a linux link name and it resulted it ugly, if benign, sysctl access attempts such as "/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc. Now it triggers an assertion failure. Let's guard all such accesses. Fixes: 32b3eb1181 Fixes: cd271d5cb1
2017-10-31 18:22:37 +01:00
if (!nm_device_get_ip_ifindex (self))
return;
trivial: re-organize IPv6 /proc property util functions
2014-05-20 15:17:13 -05:00
for (i = 0; i < G_N_ELEMENTS (ip6_properties_to_save); i++) {
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
char buf[NM_UTILS_SYSCTL_IP_CONF_PATH_BUFSIZE];
core: don't use static buffer for nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). The API with static buffers looks a bit nicer. But I think they are dangerous, because we tend to pass the buffer down several layers of the stack, and it's not immediately clear, that we don't overwrite the static buffer again (which we probably did not, but it's hard to verify that there is no bug there).
2017-10-23 13:55:54 +02:00
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
value = nm_platform_sysctl_get (nm_device_get_platform (self), NMP_SYSCTL_PATHID_ABSOLUTE (nm_utils_sysctl_ip_conf_path (AF_INET6, buf, ifname, ip6_properties_to_save[i])));
trivial: re-organize IPv6 /proc property util functions
2014-05-20 15:17:13 -05:00
if (value) {
g_hash_table_insert (priv->ip6_saved_properties,
(char *) ip6_properties_to_save[i],
value);
}
}
}
static void
restore_ip6_properties (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
GHashTableIter iter;
gpointer key, value;
g_hash_table_iter_init (&iter, priv->ip6_saved_properties);
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
while (g_hash_table_iter_next (&iter, &key, &value)) {
/* Don't touch "disable_ipv6" if we're doing userland IPv6LL */
if (priv->nm_ipv6ll && strcmp (key, "disable_ipv6") == 0)
continue;
trivial: re-organize IPv6 /proc property util functions
2014-05-20 15:17:13 -05:00
nm_device_ipv6_sysctl_set (self, key, value);
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
}
}
static inline void
set_disable_ipv6 (NMDevice *self, const char *value)
{
/* We only touch disable_ipv6 when NM is not managing the IPv6LL address */
if (NM_DEVICE_GET_PRIVATE (self)->nm_ipv6ll == FALSE)
nm_device_ipv6_sysctl_set (self, "disable_ipv6", value);
}
static inline void
set_nm_ipv6ll (NMDevice *self, gboolean enable)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
int ifindex = nm_device_get_ip_ifindex (self);
core: bounce disable_ipv6 when setting userspace IPv6 link-local (bgo #740096) The kernel does not terminate an ongoing IPv6LL address process when the IPv6LL address generation mode is set to 'none' (indicating that userspace wishes to handle IPv6LL). Next, NetworkManager does not expose IPv6 addresses internally until they have completed DAD. This means that the kernel may still be performing DAD for an IPv6LL address when NetworkManager turns userspace IPv6LL on, and when DAD is complete NetworkManager will finally pay attention to the address. If the device is in the DISCONNECTED state, NetworkManager will then generate and assume an IPv6LL-only connection on the device. Unfortunately, that behavior happens if the following is true: 1) IPv6LL addressing takes a while (eg, dad_transmits is high or the kernel takes a while for some reason) 2) the activated connection fails quickly (dhclient fails or some other fatal error terminates the activation attempt) 3) the activated connection has ipv6.method=ignore In this case, when the device was brought up and ipv6.method=ignore, NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl properties. The kernel then generated an IPv6LL address and began DAD. dhclient failed quickly, and NM deactivated the device. NM then turned off kernel IPv6LL when deactivating the device, but the kernel does not terminate the ongoing DAD. Some time after the device entered the DISCONNECTED state, the kernel finished DAD and that allowed NetworkManager to internally see the address, which caused NetworkManager to emit the 'recheck-assume' signal. This generated a new IPv6LL-only connection which was then assumed. Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during device deactivation flushes the tentative kernel IPv6LL address, thus preventing the address from being announced after userspace IPv6LL is re-enabled. The other alternative is to expose tentative addresses (eg those still doing DAD) in NMPlatform so they would be flushed when the device deactivates, but that is a larger & riskier set of changes. Reproducer: - ifconfig eth0 down - prepare a DHCPv4 connection with ipv6.method=ignore - set /proc/sys/net/ipv6/conf/all/dad_transmits to "15" - ensure that DHCPv4 will fail (replace dhclient with a script that exits after 2 seconds or something) - run NetworkManager - activate the DHCP connection and watch it immediately fail - wait for the kernel to announce the IPv6LL address after DAD finishes - watch NM "assume" the new IPv6LL connection https://bugzilla.gnome.org/show_bug.cgi?id=740096
2014-11-13 19:52:21 -06:00
char *value;
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
platform: refactor detecting kernel support We are going to add another parameter to check. Instead of adding multiple virtual functions, add a NMPlatformKernelSupportFlags flags enum.
2017-10-10 18:20:05 +02:00
if (!nm_platform_check_kernel_support (nm_device_get_platform (self),
NM_PLATFORM_KERNEL_SUPPORT_USER_IPV6LL))
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
return;
priv->nm_ipv6ll = enable;
if (ifindex > 0) {
device: tune down warning about failure to set userspace IPv6LL on non-existing device When a device gets removed externally, we still try to clear userspace IPv6LL address handling. That fails, due to non-existing device. Such a failure should not be logged as warning. <debug> [1467723214.2078] device[0x558c59335ca0] (enp0s25): disposing <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): remove_pending_action (0): 'dhcp6' not pending (expected) <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): remove_pending_action (0): 'autoconf6' not pending (expected) <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): will disable userland IPv6LL <debug> [1467723214.2079] platform-linux: link: change 20: user-ipv6ll: set IPv6 address generation mode to eui64 <trace> [1467723214.2080] platform-linux: delayed-action: schedule wait-for-nl-response (seq 92, timeout in 0.199998611) <trace> [1467723214.2080] platform-linux: delayed-action: schedule refresh-link (ifindex 20) <trace> [1467723214.2080] platform-linux: delayed-action: handle refresh-link (ifindex 20) <debug> [1467723214.2080] platform-linux: do-request-link: 20 <trace> [1467723214.2080] platform-linux: netlink: recvmsg: new message type 2, seq 92 <debug> [1467723214.2080] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 92 <trace> [1467723214.2081] platform-linux: delayed-action: complete wait-for-nl-response (seq 92, timeout in 0.199895684, failure 19 (No such device)) <trace> [1467723214.2081] platform-linux: delayed-action: schedule wait-for-nl-response (seq 93, timeout in 0.199999306) <trace> [1467723214.2081] platform-linux: delayed-action: handle wait-for-nl-response (any) <trace> [1467723214.2081] platform-linux: netlink: recvmsg: new message type 2, seq 93 <debug> [1467723214.2081] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 93 <trace> [1467723214.2082] platform-linux: delayed-action: complete wait-for-nl-response (seq 93, timeout in 0.199921142, failure 19 (No such device)) <debug> [1467723214.2082] platform-linux: do-change-link[20]: failure changing link: failure 19 (No such device) <warn> [1467723214.2082] device (enp0s25): failed to disable userspace IPv6LL address handling https://bugzilla.redhat.com/show_bug.cgi?id=1323571
2016-07-05 15:04:37 +02:00
NMPlatformError plerr;
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
const char *detail = enable ? "enable" : "disable";
_LOGD (LOGD_IP6, "will %s userland IPv6LL", detail);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
plerr = nm_platform_link_set_user_ipv6ll_enabled (nm_device_get_platform (self), ifindex, enable);
device: tune down warning about failure to set userspace IPv6LL on non-existing device When a device gets removed externally, we still try to clear userspace IPv6LL address handling. That fails, due to non-existing device. Such a failure should not be logged as warning. <debug> [1467723214.2078] device[0x558c59335ca0] (enp0s25): disposing <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): remove_pending_action (0): 'dhcp6' not pending (expected) <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): remove_pending_action (0): 'autoconf6' not pending (expected) <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): will disable userland IPv6LL <debug> [1467723214.2079] platform-linux: link: change 20: user-ipv6ll: set IPv6 address generation mode to eui64 <trace> [1467723214.2080] platform-linux: delayed-action: schedule wait-for-nl-response (seq 92, timeout in 0.199998611) <trace> [1467723214.2080] platform-linux: delayed-action: schedule refresh-link (ifindex 20) <trace> [1467723214.2080] platform-linux: delayed-action: handle refresh-link (ifindex 20) <debug> [1467723214.2080] platform-linux: do-request-link: 20 <trace> [1467723214.2080] platform-linux: netlink: recvmsg: new message type 2, seq 92 <debug> [1467723214.2080] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 92 <trace> [1467723214.2081] platform-linux: delayed-action: complete wait-for-nl-response (seq 92, timeout in 0.199895684, failure 19 (No such device)) <trace> [1467723214.2081] platform-linux: delayed-action: schedule wait-for-nl-response (seq 93, timeout in 0.199999306) <trace> [1467723214.2081] platform-linux: delayed-action: handle wait-for-nl-response (any) <trace> [1467723214.2081] platform-linux: netlink: recvmsg: new message type 2, seq 93 <debug> [1467723214.2081] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 93 <trace> [1467723214.2082] platform-linux: delayed-action: complete wait-for-nl-response (seq 93, timeout in 0.199921142, failure 19 (No such device)) <debug> [1467723214.2082] platform-linux: do-change-link[20]: failure changing link: failure 19 (No such device) <warn> [1467723214.2082] device (enp0s25): failed to disable userspace IPv6LL address handling https://bugzilla.redhat.com/show_bug.cgi?id=1323571
2016-07-05 15:04:37 +02:00
if (plerr != NM_PLATFORM_ERROR_SUCCESS) {
_NMLOG (plerr == NM_PLATFORM_ERROR_NOT_FOUND ? LOGL_DEBUG : LOGL_WARN,
LOGD_IP6,
"failed to %s userspace IPv6LL address handling (%s)",
detail,
platform: pass string buffer to nm_platform_error_to_string() and print numeric errno Change the output of nm_platform_error_to_string() to print the numeric value. Also, accept a string buffer instead of using an alloca() allocated buffer. There is still a macro to provide the previous functionality, but it was ill-suited to call from inside a loop.
2017-08-21 19:18:45 +02:00
nm_platform_error_to_string_a (plerr));
device: tune down warning about failure to set userspace IPv6LL on non-existing device When a device gets removed externally, we still try to clear userspace IPv6LL address handling. That fails, due to non-existing device. Such a failure should not be logged as warning. <debug> [1467723214.2078] device[0x558c59335ca0] (enp0s25): disposing <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): remove_pending_action (0): 'dhcp6' not pending (expected) <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): remove_pending_action (0): 'autoconf6' not pending (expected) <debug> [1467723214.2079] device[0x558c59335ca0] (enp0s25): will disable userland IPv6LL <debug> [1467723214.2079] platform-linux: link: change 20: user-ipv6ll: set IPv6 address generation mode to eui64 <trace> [1467723214.2080] platform-linux: delayed-action: schedule wait-for-nl-response (seq 92, timeout in 0.199998611) <trace> [1467723214.2080] platform-linux: delayed-action: schedule refresh-link (ifindex 20) <trace> [1467723214.2080] platform-linux: delayed-action: handle refresh-link (ifindex 20) <debug> [1467723214.2080] platform-linux: do-request-link: 20 <trace> [1467723214.2080] platform-linux: netlink: recvmsg: new message type 2, seq 92 <debug> [1467723214.2080] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 92 <trace> [1467723214.2081] platform-linux: delayed-action: complete wait-for-nl-response (seq 92, timeout in 0.199895684, failure 19 (No such device)) <trace> [1467723214.2081] platform-linux: delayed-action: schedule wait-for-nl-response (seq 93, timeout in 0.199999306) <trace> [1467723214.2081] platform-linux: delayed-action: handle wait-for-nl-response (any) <trace> [1467723214.2081] platform-linux: netlink: recvmsg: new message type 2, seq 93 <debug> [1467723214.2081] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 93 <trace> [1467723214.2082] platform-linux: delayed-action: complete wait-for-nl-response (seq 93, timeout in 0.199921142, failure 19 (No such device)) <debug> [1467723214.2082] platform-linux: do-change-link[20]: failure changing link: failure 19 (No such device) <warn> [1467723214.2082] device (enp0s25): failed to disable userspace IPv6LL address handling https://bugzilla.redhat.com/show_bug.cgi?id=1323571
2016-07-05 15:04:37 +02:00
}
core: bounce disable_ipv6 when setting userspace IPv6 link-local (bgo #740096) The kernel does not terminate an ongoing IPv6LL address process when the IPv6LL address generation mode is set to 'none' (indicating that userspace wishes to handle IPv6LL). Next, NetworkManager does not expose IPv6 addresses internally until they have completed DAD. This means that the kernel may still be performing DAD for an IPv6LL address when NetworkManager turns userspace IPv6LL on, and when DAD is complete NetworkManager will finally pay attention to the address. If the device is in the DISCONNECTED state, NetworkManager will then generate and assume an IPv6LL-only connection on the device. Unfortunately, that behavior happens if the following is true: 1) IPv6LL addressing takes a while (eg, dad_transmits is high or the kernel takes a while for some reason) 2) the activated connection fails quickly (dhclient fails or some other fatal error terminates the activation attempt) 3) the activated connection has ipv6.method=ignore In this case, when the device was brought up and ipv6.method=ignore, NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl properties. The kernel then generated an IPv6LL address and began DAD. dhclient failed quickly, and NM deactivated the device. NM then turned off kernel IPv6LL when deactivating the device, but the kernel does not terminate the ongoing DAD. Some time after the device entered the DISCONNECTED state, the kernel finished DAD and that allowed NetworkManager to internally see the address, which caused NetworkManager to emit the 'recheck-assume' signal. This generated a new IPv6LL-only connection which was then assumed. Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during device deactivation flushes the tentative kernel IPv6LL address, thus preventing the address from being announced after userspace IPv6LL is re-enabled. The other alternative is to expose tentative addresses (eg those still doing DAD) in NMPlatform so they would be flushed when the device deactivates, but that is a larger & riskier set of changes. Reproducer: - ifconfig eth0 down - prepare a DHCPv4 connection with ipv6.method=ignore - set /proc/sys/net/ipv6/conf/all/dad_transmits to "15" - ensure that DHCPv4 will fail (replace dhclient with a script that exits after 2 seconds or something) - run NetworkManager - activate the DHCP connection and watch it immediately fail - wait for the kernel to announce the IPv6LL address after DAD finishes - watch NM "assume" the new IPv6LL connection https://bugzilla.gnome.org/show_bug.cgi?id=740096
2014-11-13 19:52:21 -06:00
if (enable) {
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
char buf[NM_UTILS_SYSCTL_IP_CONF_PATH_BUFSIZE];
core: don't use static buffer for nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). The API with static buffers looks a bit nicer. But I think they are dangerous, because we tend to pass the buffer down several layers of the stack, and it's not immediately clear, that we don't overwrite the static buffer again (which we probably did not, but it's hard to verify that there is no bug there).
2017-10-23 13:55:54 +02:00
core: bounce disable_ipv6 when setting userspace IPv6 link-local (bgo #740096) The kernel does not terminate an ongoing IPv6LL address process when the IPv6LL address generation mode is set to 'none' (indicating that userspace wishes to handle IPv6LL). Next, NetworkManager does not expose IPv6 addresses internally until they have completed DAD. This means that the kernel may still be performing DAD for an IPv6LL address when NetworkManager turns userspace IPv6LL on, and when DAD is complete NetworkManager will finally pay attention to the address. If the device is in the DISCONNECTED state, NetworkManager will then generate and assume an IPv6LL-only connection on the device. Unfortunately, that behavior happens if the following is true: 1) IPv6LL addressing takes a while (eg, dad_transmits is high or the kernel takes a while for some reason) 2) the activated connection fails quickly (dhclient fails or some other fatal error terminates the activation attempt) 3) the activated connection has ipv6.method=ignore In this case, when the device was brought up and ipv6.method=ignore, NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl properties. The kernel then generated an IPv6LL address and began DAD. dhclient failed quickly, and NM deactivated the device. NM then turned off kernel IPv6LL when deactivating the device, but the kernel does not terminate the ongoing DAD. Some time after the device entered the DISCONNECTED state, the kernel finished DAD and that allowed NetworkManager to internally see the address, which caused NetworkManager to emit the 'recheck-assume' signal. This generated a new IPv6LL-only connection which was then assumed. Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during device deactivation flushes the tentative kernel IPv6LL address, thus preventing the address from being announced after userspace IPv6LL is re-enabled. The other alternative is to expose tentative addresses (eg those still doing DAD) in NMPlatform so they would be flushed when the device deactivates, but that is a larger & riskier set of changes. Reproducer: - ifconfig eth0 down - prepare a DHCPv4 connection with ipv6.method=ignore - set /proc/sys/net/ipv6/conf/all/dad_transmits to "15" - ensure that DHCPv4 will fail (replace dhclient with a script that exits after 2 seconds or something) - run NetworkManager - activate the DHCP connection and watch it immediately fail - wait for the kernel to announce the IPv6LL address after DAD finishes - watch NM "assume" the new IPv6LL connection https://bugzilla.gnome.org/show_bug.cgi?id=740096
2014-11-13 19:52:21 -06:00
/* Bounce IPv6 to ensure the kernel stops IPv6LL address generation */
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
value = nm_platform_sysctl_get (nm_device_get_platform (self),
core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path() and nm_utils_ip6_property_path(). Also, rename to nm_utils_sysctl_ip_conf_path().
2017-10-23 13:55:54 +02:00
NMP_SYSCTL_PATHID_ABSOLUTE (nm_utils_sysctl_ip_conf_path (AF_INET6, buf, nm_device_get_ip_iface (self), "disable_ipv6")));
core: force disable_ipv6=0 when turning on userspace IPv6LL (bgo #741773) If a device assumes a connection without activating a user-requested or NM-requested connection, then disable_ipv6 is not touched. When the device is deactivated, it still isn't touched even though userspace IPv6LL is enabled. This could lead to an user-requested activation with IPv6 configuration, but disable_ipv6=1. Whenever userspace IPv6LL is turned on, we should also set disable_ipv6=0 to ensure IPv6 can function. Userspace IPv6LL will ensure that the interface does not have an address until the user/connection requests it, which was the only reason that NM touched disable_ipv6 anyway. fixes:NetworkManager_Test203_testcase_286589 fixes:NetworkManager_Test204_testcase_286590 https://bugzilla.gnome.org/show_bug.cgi?id=741773
2014-12-19 10:45:31 -06:00
if (g_strcmp0 (value, "0") == 0)
core: bounce disable_ipv6 when setting userspace IPv6 link-local (bgo #740096) The kernel does not terminate an ongoing IPv6LL address process when the IPv6LL address generation mode is set to 'none' (indicating that userspace wishes to handle IPv6LL). Next, NetworkManager does not expose IPv6 addresses internally until they have completed DAD. This means that the kernel may still be performing DAD for an IPv6LL address when NetworkManager turns userspace IPv6LL on, and when DAD is complete NetworkManager will finally pay attention to the address. If the device is in the DISCONNECTED state, NetworkManager will then generate and assume an IPv6LL-only connection on the device. Unfortunately, that behavior happens if the following is true: 1) IPv6LL addressing takes a while (eg, dad_transmits is high or the kernel takes a while for some reason) 2) the activated connection fails quickly (dhclient fails or some other fatal error terminates the activation attempt) 3) the activated connection has ipv6.method=ignore In this case, when the device was brought up and ipv6.method=ignore, NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl properties. The kernel then generated an IPv6LL address and began DAD. dhclient failed quickly, and NM deactivated the device. NM then turned off kernel IPv6LL when deactivating the device, but the kernel does not terminate the ongoing DAD. Some time after the device entered the DISCONNECTED state, the kernel finished DAD and that allowed NetworkManager to internally see the address, which caused NetworkManager to emit the 'recheck-assume' signal. This generated a new IPv6LL-only connection which was then assumed. Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during device deactivation flushes the tentative kernel IPv6LL address, thus preventing the address from being announced after userspace IPv6LL is re-enabled. The other alternative is to expose tentative addresses (eg those still doing DAD) in NMPlatform so they would be flushed when the device deactivates, but that is a larger & riskier set of changes. Reproducer: - ifconfig eth0 down - prepare a DHCPv4 connection with ipv6.method=ignore - set /proc/sys/net/ipv6/conf/all/dad_transmits to "15" - ensure that DHCPv4 will fail (replace dhclient with a script that exits after 2 seconds or something) - run NetworkManager - activate the DHCP connection and watch it immediately fail - wait for the kernel to announce the IPv6LL address after DAD finishes - watch NM "assume" the new IPv6LL connection https://bugzilla.gnome.org/show_bug.cgi?id=740096
2014-11-13 19:52:21 -06:00
nm_device_ipv6_sysctl_set (self, "disable_ipv6", "1");
g_free (value);
core: force disable_ipv6=0 when turning on userspace IPv6LL (bgo #741773) If a device assumes a connection without activating a user-requested or NM-requested connection, then disable_ipv6 is not touched. When the device is deactivated, it still isn't touched even though userspace IPv6LL is enabled. This could lead to an user-requested activation with IPv6 configuration, but disable_ipv6=1. Whenever userspace IPv6LL is turned on, we should also set disable_ipv6=0 to ensure IPv6 can function. Userspace IPv6LL will ensure that the interface does not have an address until the user/connection requests it, which was the only reason that NM touched disable_ipv6 anyway. fixes:NetworkManager_Test203_testcase_286589 fixes:NetworkManager_Test204_testcase_286590 https://bugzilla.gnome.org/show_bug.cgi?id=741773
2014-12-19 10:45:31 -06:00
/* Ensure IPv6 is enabled */
nm_device_ipv6_sysctl_set (self, "disable_ipv6", "0");
core: bounce disable_ipv6 when setting userspace IPv6 link-local (bgo #740096) The kernel does not terminate an ongoing IPv6LL address process when the IPv6LL address generation mode is set to 'none' (indicating that userspace wishes to handle IPv6LL). Next, NetworkManager does not expose IPv6 addresses internally until they have completed DAD. This means that the kernel may still be performing DAD for an IPv6LL address when NetworkManager turns userspace IPv6LL on, and when DAD is complete NetworkManager will finally pay attention to the address. If the device is in the DISCONNECTED state, NetworkManager will then generate and assume an IPv6LL-only connection on the device. Unfortunately, that behavior happens if the following is true: 1) IPv6LL addressing takes a while (eg, dad_transmits is high or the kernel takes a while for some reason) 2) the activated connection fails quickly (dhclient fails or some other fatal error terminates the activation attempt) 3) the activated connection has ipv6.method=ignore In this case, when the device was brought up and ipv6.method=ignore, NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl properties. The kernel then generated an IPv6LL address and began DAD. dhclient failed quickly, and NM deactivated the device. NM then turned off kernel IPv6LL when deactivating the device, but the kernel does not terminate the ongoing DAD. Some time after the device entered the DISCONNECTED state, the kernel finished DAD and that allowed NetworkManager to internally see the address, which caused NetworkManager to emit the 'recheck-assume' signal. This generated a new IPv6LL-only connection which was then assumed. Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during device deactivation flushes the tentative kernel IPv6LL address, thus preventing the address from being announced after userspace IPv6LL is re-enabled. The other alternative is to expose tentative addresses (eg those still doing DAD) in NMPlatform so they would be flushed when the device deactivates, but that is a larger & riskier set of changes. Reproducer: - ifconfig eth0 down - prepare a DHCPv4 connection with ipv6.method=ignore - set /proc/sys/net/ipv6/conf/all/dad_transmits to "15" - ensure that DHCPv4 will fail (replace dhclient with a script that exits after 2 seconds or something) - run NetworkManager - activate the DHCP connection and watch it immediately fail - wait for the kernel to announce the IPv6LL address after DAD finishes - watch NM "assume" the new IPv6LL connection https://bugzilla.gnome.org/show_bug.cgi?id=740096
2014-11-13 19:52:21 -06:00
}
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
}
trivial: re-organize IPv6 /proc property util functions
2014-05-20 15:17:13 -05:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
core/rdisc: add support for IPv6 privacy Add support for ipv6-private addresses. This feature needs support from the kernel and libnl. If there is no system support, temporary addresses are not supported. Log a warning in this case. Depending on whether ipv6-privacy (use_tempaddr) is enabled, we add the address flag IFA_F_MANAGETEMPADDR and the kernel will add temporary addresses for us. https://bugzilla.gnome.org/show_bug.cgi?id=705170 https://bugzilla.redhat.com/show_bug.cgi?id=1003859 https://bugzilla.redhat.com/show_bug.cgi?id=1047139 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-03 17:03:35 +01:00
static NMSettingIP6ConfigPrivacy
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
_ip6_privacy_clamp (NMSettingIP6ConfigPrivacy use_tempaddr)
core/rdisc: add support for IPv6 privacy Add support for ipv6-private addresses. This feature needs support from the kernel and libnl. If there is no system support, temporary addresses are not supported. Log a warning in this case. Depending on whether ipv6-privacy (use_tempaddr) is enabled, we add the address flag IFA_F_MANAGETEMPADDR and the kernel will add temporary addresses for us. https://bugzilla.gnome.org/show_bug.cgi?id=705170 https://bugzilla.redhat.com/show_bug.cgi?id=1003859 https://bugzilla.redhat.com/show_bug.cgi?id=1047139 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-03 17:03:35 +01:00
{
switch (use_tempaddr) {
case NM_SETTING_IP6_CONFIG_PRIVACY_DISABLED:
case NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_TEMP_ADDR:
case NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_PUBLIC_ADDR:
return use_tempaddr;
default:
return NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN;
}
}
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
static NMSettingIP6ConfigPrivacy
_ip6_privacy_get (NMDevice *self)
{
NMSettingIP6ConfigPrivacy ip6_privacy;
gs_free char *value = NULL;
NMConnection *connection;
g_return_val_if_fail (self, NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN);
device: remove reading ipv6 privacy setting from sysctl Since introduction for support of ip6-privacy (use_tempaddr, RFC4941) with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, the sysctl value from /etc was always read first. This is problematic, because an explicit setting in the connection should not be ignored over a global configuration. Drop that old behavior. It was also problematic, because we did not read any files under /etc/sysctl.d (except for sysctl.conf). Also, we did not honor per-interface configurations. Now we also use as last fallback the value from /proc/sys/net/ipv6/conf/default/use_tempaddr That has the advantage of falling back to the system default value so that NM doesn't need to have it's own default policy (Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525). This is a change in behavior.
2015-06-02 17:38:07 +02:00
/* 1.) First look at the per-connection setting. If it is not -1 (unknown),
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
* use it. */
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
if (connection) {
NMSettingIPConfig *s_ip6 = nm_connection_get_setting_ip6_config (connection);
if (s_ip6) {
ip6_privacy = nm_setting_ip6_config_get_ip6_privacy (NM_SETTING_IP6_CONFIG (s_ip6));
ip6_privacy = _ip6_privacy_clamp (ip6_privacy);
if (ip6_privacy != NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN)
return ip6_privacy;
}
}
config: add macros NM_CONFIG_GET_DATA and NM_CONFIG_GET_DATA_ORIG
2015-06-09 08:47:41 +02:00
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
device: remove reading ipv6 privacy setting from sysctl Since introduction for support of ip6-privacy (use_tempaddr, RFC4941) with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, the sysctl value from /etc was always read first. This is problematic, because an explicit setting in the connection should not be ignored over a global configuration. Drop that old behavior. It was also problematic, because we did not read any files under /etc/sysctl.d (except for sysctl.conf). Also, we did not honor per-interface configurations. Now we also use as last fallback the value from /proc/sys/net/ipv6/conf/default/use_tempaddr That has the advantage of falling back to the system default value so that NM doesn't need to have it's own default policy (Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525). This is a change in behavior.
2015-06-02 17:38:07 +02:00
"ipv6.ip6-privacy", self);
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
device: remove reading ipv6 privacy setting from sysctl Since introduction for support of ip6-privacy (use_tempaddr, RFC4941) with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, the sysctl value from /etc was always read first. This is problematic, because an explicit setting in the connection should not be ignored over a global configuration. Drop that old behavior. It was also problematic, because we did not read any files under /etc/sysctl.d (except for sysctl.conf). Also, we did not honor per-interface configurations. Now we also use as last fallback the value from /proc/sys/net/ipv6/conf/default/use_tempaddr That has the advantage of falling back to the system default value so that NM doesn't need to have it's own default policy (Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525). This is a change in behavior.
2015-06-02 17:38:07 +02:00
/* 2.) use the default value from the configuration. */
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
ip6_privacy = _nm_utils_ascii_str_to_int64 (value, 10,
NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN,
NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_TEMP_ADDR,
NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN);
if (ip6_privacy != NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN)
return ip6_privacy;
device: avoid touching sysctls for devices without platform link Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to cunstruct sysctl paths and it is way less tolerant towards using something that is not an interface name in the path. It's always been incorrect to assume the ifname is a linux link name and it resulted it ugly, if benign, sysctl access attempts such as "/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc. Now it triggers an assertion failure. Let's guard all such accesses. Fixes: 32b3eb1181 Fixes: cd271d5cb1
2017-10-31 18:22:37 +01:00
if (!nm_device_get_ip_ifindex (self))
return NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN;;
device: remove reading ipv6 privacy setting from sysctl Since introduction for support of ip6-privacy (use_tempaddr, RFC4941) with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, the sysctl value from /etc was always read first. This is problematic, because an explicit setting in the connection should not be ignored over a global configuration. Drop that old behavior. It was also problematic, because we did not read any files under /etc/sysctl.d (except for sysctl.conf). Also, we did not honor per-interface configurations. Now we also use as last fallback the value from /proc/sys/net/ipv6/conf/default/use_tempaddr That has the advantage of falling back to the system default value so that NM doesn't need to have it's own default policy (Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525). This is a change in behavior.
2015-06-02 17:38:07 +02:00
/* 3.) No valid default-value configured. Fallback to reading sysctl.
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
*
* Instead of reading static config files in /etc, just read the current sysctl value.
* This works as NM only writes to "/proc/sys/net/ipv6/conf/IFNAME/use_tempaddr", but leaves
* the "default" entry untouched. */
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
ip6_privacy = nm_platform_sysctl_get_int32 (nm_device_get_platform (self), NMP_SYSCTL_PATHID_ABSOLUTE ("/proc/sys/net/ipv6/conf/default/use_tempaddr"), NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN);
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
return _ip6_privacy_clamp (ip6_privacy);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
static gboolean
ip6_requires_slaves (NMConnection *connection)
{
core: don't have IP4 and IP6 configs on slaves Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
2013-10-14 10:38:56 -04:00
const char *method;
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
core: don't have IP4 and IP6 configs on slaves Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
2013-10-14 10:38:56 -04:00
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG);
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
/* SLAAC, DHCP, and Link-Local depend on connectivity (and thus slaves)
device: ipv6.method=link-local does not need slaves It already waits for carrier, which is sufficient -- DAD won't start until there's carrier.
2016-11-05 18:37:53 +01:00
* to complete addressing. SLAAC and DHCP need a peer to provide a prefix.
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
*/
settings: make connections always have s_ip4 and s_ip6 Make sure that all connections returned from NMSettings or created via AddAndActivateConnection have an NMSettingIP4Config and an NMSettingIP6Config, with non-NULL methods, and get rid of now-unnecessary checks for those. Also move the slaves-can't-have-IP-config checks into the platform-independent code as well. This also gets rid of spurious "ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a slave ifcfg file. Partly based on a patch from Pavel. https://bugzilla.gnome.org/show_bug.cgi?id=708875
2013-09-26 17:34:23 -04:00
return strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_AUTO) == 0
device: ipv6.method=link-local does not need slaves It already waits for carrier, which is sufficient -- DAD won't start until there's carrier.
2016-11-05 18:37:53 +01:00
|| strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_DHCP) == 0;
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
}
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
static NMActStageReturn
core: remove "real_" prefix from method implementation names The idea was copied from gtk, but it's only used there in cases where the method's wrapper function and default implementation would otherwise have the same name, which never happens in NM because our method implementations aren't prefixed with the type name, so it's just noise here.
2012-09-27 12:12:15 -04:00
act_stage3_ip6_config_start (NMDevice *self,
NMIP6Config **out_config,
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NMDeviceStateReason *out_failure_reason)
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
{
Add NMIP6Manager to handle IPv6 addrconf Automatic IPv6 configuration is handled by the kernel, but to integrate it properly with NetworkManager, we need to watch what the kernel does to see whether or not it was successful (so that we can let the user know if there is no IPv6 router present, for example). NMIP6Manager takes care of this.
2009-07-30 13:50:42 -04:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
ip6: fix manual IP config application
2010-04-30 15:49:41 -07:00
NMActStageReturn ret = NM_ACT_STAGE_RETURN_FAILURE;
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
NMConnection *connection;
core: don't have IP4 and IP6 configs on slaves Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
2013-10-14 10:38:56 -04:00
const char *method;
core: add support for IPv6 Privacy Extensions for SLAAC (RFC4941) (bgo #633233)
2012-02-21 15:44:19 +01:00
NMSettingIP6ConfigPrivacy ip6_privacy = NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN;
device: only set use_tempaddr sysctl for non-assumed devices and only if the activation stage is not about to fail hard.
2016-08-31 19:11:25 +02:00
const char *ip6_privacy_str = "0";
Add NMIP6Manager to handle IPv6 addrconf Automatic IPv6 configuration is handled by the kernel, but to integrate it properly with NetworkManager, we need to watch what the kernel does to see whether or not it was successful (so that we can let the user know if there is no IPv6 router present, for example). NMIP6Manager takes care of this.
2009-07-30 13:50:42 -04:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
g_return_val_if_fail (connection, NM_ACT_STAGE_RETURN_FAILURE);
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
device: fix a couple of copy & paste errors
2015-03-16 18:27:35 +01:00
if ( connection_ip6_method_requires_carrier (connection, NULL)
device: transform NM_DEVICE_IS_MASTER gobject property to field in NMDeviceClass We don't need this flexibility of having a full fledged GObject property for is-master. The property value only depends on the device's class.
2017-06-01 23:08:30 +02:00
&& nm_device_is_master (self)
core: postpone non-static master IP configuration until carrier This got broken at some point. The intent of ignore-carrier was always to ignore the carrier for IP configuration for static/manual connections, but never for DHCP/SLAAC where a link is actually required. Thus when checking whether to postpone IP configuration for a master interface that's using DHCP/SLAAC, don't allow ignore-carrier to factor into the decision.
2014-02-25 18:00:34 -06:00
&& !priv->carrier) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_IP6 | LOGD_DEVICE,
"IPv6 config waiting until carrier is on");
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
return NM_ACT_STAGE_RETURN_IP_WAIT;
wired: ignore carrier state for manual/static bridge and bond connections NM is supposed to ignore carrier and slave states for manual/static connections when bringing up bonds and bridges, on the theory that since static configuration does not require connectivity, there's no need to wait for that connectivity to happen. This wasn't happening during the IP configuration phase, but was happening before getting to the IP config phase where the device waits for slaves before starting IP configuration if the method requires connectivity.
2013-06-07 15:11:23 -05:00
}
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
device: transform NM_DEVICE_IS_MASTER gobject property to field in NMDeviceClass We don't need this flexibility of having a full fledged GObject property for is-master. The property value only depends on the device's class.
2017-06-01 23:08:30 +02:00
if (nm_device_is_master (self) && ip6_requires_slaves (connection)) {
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
/* If the master has no ready slaves, and depends on slaves for
* a successful IPv6 attempt, then postpone IPv6 addressing.
*/
device: simplify check for ready slaves
2017-05-14 09:52:18 +02:00
if (!have_any_ready_slaves (self)) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_DEVICE | LOGD_IP6,
"IPv6 config waiting until slaves are ready");
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
return NM_ACT_STAGE_RETURN_IP_WAIT;
core: generalize waiting for IP config until slaves are ready Instead of duplicating the code in bridge and bond, move the logic to the base class and key it off whether or not the device is a master.
2013-01-25 11:59:05 -06:00
}
}
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
priv->dhcp6.mode = NM_NDISC_DHCP_LEVEL_NONE;
device: retry DHCPv6 when a lease expires Make DHCPv6 more robust WRT temporary failures of servers by retrying DHCP for a predefined number of times at regular intervals when the lease expires. https://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 15:09:54 +02:00
priv->dhcp6.num_tries_left = DHCP_NUM_TRIES_MAX;
dhcp6: track client mode better and handle info-only early-exit Ignore early exits of the client in info-only mode; since there is no address lease the client doesn't need to stick around after getting DNS/etc options from the server.
2010-05-01 10:16:38 -07:00
core: loosen master device carrier check before IP configuration Previously a master device would wait for a carrier before starting IP configuration only for 'manual' connections, but that's not quite broad enough. We also want to allow SHARED methods to proceed immediately since they are also effectively static/manual configuration. Use the newly split out methods for checking whether a connection requires a carrier or not to allow the SHARED method to proceed for master devices without a carrier. For example, this allows bridge configurations with tun/tap ports to set up SHARED addressing before the tun/tap gets a carrier which only happens when something opens the other side of the tun/tap (like the VM or container).
2014-10-14 11:41:36 -05:00
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG);
devices: use disable_ipv6 as appropriate Set and clear disable_ipv6 on devices as needed to ensure that: 1) devices never get IPv6 link local addresses until they are actually activated 2) devices always lose their IPv6 link local addresses when they are deactivated 3) slaves never get IPv6 link local addresses at all https://bugzilla.gnome.org/show_bug.cgi?id=700414 https://bugzilla.redhat.com/show_bug.cgi?id=1004255
2013-10-08 13:51:00 -04:00
if (strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_IGNORE) == 0) {
device: avoid touching IPv6 on "external" connections without IPv6 conf When a device managed by NetworkManager is configured manually (adding ip addresses), NetworkManager will track the device configuration with an in-memory only config, marking the device as "external". Devices marked external should be just tracked but left untouched. This does not happens on current code base: if an ipv4 address is added, NM generates the in-memory connection, marking the ipv6.method as "ignore". While activating the connection, NM will process the IPv6 "ignore" method: this implies leaving the IPv6LL address generation to the kernel. To trigger this NM will disable/enable IPv6 on the interface. This not only may change the device configuration but may cause also a potential race with an external IPv6 assignment on the device. NetworkManager should do nothing to IPv6 when method is "ignore" and connection is marked as "external": this commit fixes this behavior. Note that if/once an IPv6 address is externally added, IPv6 method in the tracked connection is changed to "manual" and a link local address will be generated if needed. https://bugzilla.redhat.com/show_bug.cgi?id=1462260
2017-09-19 18:25:21 +02:00
if ( !priv->master
&& !nm_device_sys_iface_state_is_external (self)) {
core: don't bounce disable_ipv6 if NM IPv6LL wasn't enabled (bgo #740702) If NM IPv6LL wasn't enabled then there is no need to bounce disable_ipv6 to tell the kernel to re-enable kernel IPv6LL, because kernel IPv6LL is already enabled. https://bugzilla.gnome.org/show_bug.cgi?id=740702
2014-12-16 14:38:17 -06:00
gboolean old_nm_ipv6ll = priv->nm_ipv6ll;
core: let kernel add IPv6LL address when method=ignore (rh #1132938) The IPv6LL address handling in userspace patches failed to handle the case where the IPv6 method was 'ignore'. Previously the kernel would usually add the IPv6LL address itself, but if NM has turned off kernel IPv6LL then obviously this wouldn't happen. So when the method is 'ignore', turn off userspace IPv6LL handling and bounce disable_ipv6 to make the kernel add the IPv6LL address if it wants to.
2014-10-02 15:58:44 -05:00
/* When activating an IPv6 'ignore' connection we need to revert back
* to kernel IPv6LL, but the kernel won't actually assign an address
* to the interface until disable_ipv6 is bounced.
*/
set_nm_ipv6ll (self, FALSE);
core: don't bounce disable_ipv6 if NM IPv6LL wasn't enabled (bgo #740702) If NM IPv6LL wasn't enabled then there is no need to bounce disable_ipv6 to tell the kernel to re-enable kernel IPv6LL, because kernel IPv6LL is already enabled. https://bugzilla.gnome.org/show_bug.cgi?id=740702
2014-12-16 14:38:17 -06:00
if (old_nm_ipv6ll == TRUE)
nm_device_ipv6_sysctl_set (self, "disable_ipv6", "1");
devices: use disable_ipv6 as appropriate Set and clear disable_ipv6 on devices as needed to ensure that: 1) devices never get IPv6 link local addresses until they are actually activated 2) devices always lose their IPv6 link local addresses when they are deactivated 3) slaves never get IPv6 link local addresses at all https://bugzilla.gnome.org/show_bug.cgi?id=700414 https://bugzilla.redhat.com/show_bug.cgi?id=1004255
2013-10-08 13:51:00 -04:00
restore_ip6_properties (self);
core: let kernel add IPv6LL address when method=ignore (rh #1132938) The IPv6LL address handling in userspace patches failed to handle the case where the IPv6 method was 'ignore'. Previously the kernel would usually add the IPv6LL address itself, but if NM has turned off kernel IPv6LL then obviously this wouldn't happen. So when the method is 'ignore', turn off userspace IPv6LL handling and bounce disable_ipv6 to make the kernel add the IPv6LL address if it wants to.
2014-10-02 15:58:44 -05:00
}
device: don't set ip4_state=IP_FAIL for ipv4.method=disabled ... and don't set ip6_state=IP_FAIL for ipv6.method=ignore. The disabled state is like having an empty NMIP4Config object. It should not result in %IP_FAIL state. Instead, we just want to proceed and commit an empty NMIP4Config instance. This was introduced by commit 0652d9c5961e4636eab87647af890aaf8c3e3269, which I think was wrong. Likewise, for ipv6.method=ignore we also don't want to mark the IP state as failed. Instead, we want to proceed and set IP_DONE right away -- without commiting anything, which is a difference to the IPv4 case. This is especially important, because an ip4_state/ip6_state of IP_FAIL causes nm_device_can_assume_active_connection() to return FALSE, which means we unmanage devices at shutdown. Ony might say that it doesn't matter so much for a device without IP configuration, but imagine a bond with VLANs on top that only has Layer 2 configuration. This will bring down the entire stack. With this change, devices with IP methods disabled/ignore stay up on exit of NetworkManager (rh#1371126). Of course, that means on restart software devices stay unamanged due to external-down (because since commit e1edcda, devices without IP address are also external-down). So, this really just fixes one scenario, breaking another one. This should be fixed with bgo#746440 by not assuming connections. https://bugzilla.redhat.com/show_bug.cgi?id=1371126
2016-08-29 15:37:55 +02:00
return NM_ACT_STAGE_RETURN_IP_DONE;
devices: use disable_ipv6 as appropriate Set and clear disable_ipv6 on devices as needed to ensure that: 1) devices never get IPv6 link local addresses until they are actually activated 2) devices always lose their IPv6 link local addresses when they are deactivated 3) slaves never get IPv6 link local addresses at all https://bugzilla.gnome.org/show_bug.cgi?id=700414 https://bugzilla.redhat.com/show_bug.cgi?id=1004255
2013-10-08 13:51:00 -04:00
}
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
/* Ensure the MTU makes sense. If it was below 1280 the kernel would not
* expose any ipv6 sysctls or allow presence of any addresses on the interface,
* including LL, which * would make it impossible to autoconfigure MTU to a
* correct value. */
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
_commit_mtu (self, priv->ip4_config);
nm-device: avoid improper IPv6 MTU configuration Ensure it's always (before address configuration starts and on updates) >= 1280 and not higher than the device MTU.
2015-02-25 15:35:26 +01:00
core: let kernel add IPv6LL address when method=ignore (rh #1132938) The IPv6LL address handling in userspace patches failed to handle the case where the IPv6 method was 'ignore'. Previously the kernel would usually add the IPv6LL address itself, but if NM has turned off kernel IPv6LL then obviously this wouldn't happen. So when the method is 'ignore', turn off userspace IPv6LL handling and bounce disable_ipv6 to make the kernel add the IPv6LL address if it wants to.
2014-10-02 15:58:44 -05:00
/* Any method past this point requires an IPv6LL address. Use NM-controlled
* IPv6LL if this is not an assumed connection, since assumed connections
* will already have IPv6 set up.
*/
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (!nm_device_sys_iface_state_is_external_or_assume (self))
core: let kernel add IPv6LL address when method=ignore (rh #1132938) The IPv6LL address handling in userspace patches failed to handle the case where the IPv6 method was 'ignore'. Previously the kernel would usually add the IPv6LL address itself, but if NM has turned off kernel IPv6LL then obviously this wouldn't happen. So when the method is 'ignore', turn off userspace IPv6LL handling and bounce disable_ipv6 to make the kernel add the IPv6LL address if it wants to.
2014-10-02 15:58:44 -05:00
set_nm_ipv6ll (self, TRUE);
devices: use disable_ipv6 as appropriate Set and clear disable_ipv6 on devices as needed to ensure that: 1) devices never get IPv6 link local addresses until they are actually activated 2) devices always lose their IPv6 link local addresses when they are deactivated 3) slaves never get IPv6 link local addresses at all https://bugzilla.gnome.org/show_bug.cgi?id=700414 https://bugzilla.redhat.com/show_bug.cgi?id=1004255
2013-10-08 13:51:00 -04:00
/* Re-enable IPv6 on the interface */
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
set_disable_ipv6 (self, "0");
devices: use disable_ipv6 as appropriate Set and clear disable_ipv6 on devices as needed to ensure that: 1) devices never get IPv6 link local addresses until they are actually activated 2) devices always lose their IPv6 link local addresses when they are deactivated 3) slaves never get IPv6 link local addresses at all https://bugzilla.gnome.org/show_bug.cgi?id=700414 https://bugzilla.redhat.com/show_bug.cgi?id=1004255
2013-10-08 13:51:00 -04:00
device: synchronize IPv6 configuration in stage3 (take 2) Most of the IPv6 methods require a non-tentative link local address configured on the interface; we look at priv->ip6_config to determine if such address exist. If the configuration is out-of-sync, we may proceed with configuration when the link-local address does not exist or is still tentative, especially because we toggle the "disable_ipv6" sysctl parameter just before, which clears all IPv6 addresses on the interface. Ensure that priv->ext_ip6_config_captured is up-to-date before continuing with the IPv6 configuration, and use it to determine whether suitable addresses are present. Fixes test: @ipv6_set_ra_announced_mtu Fixes: 8f4caab60196132c2fd0eb4a444f93f78f130e8e
2017-05-06 10:56:21 +02:00
/* Synchronize external IPv6 configuration with kernel, since
* linklocal6_start() uses the information there to determine if we can
* proceed with the selected method (SLAAC, DHCP, link-local).
*/
nm_platform_process_events (nm_device_get_platform (self));
g_clear_object (&priv->ext_ip6_config_captured);
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
priv->ext_ip6_config_captured = nm_ip6_config_capture (nm_device_get_multi_index (self),
nm_device_get_platform (self),
device: capture the IP6 configuration on the IP interface Fixes a crash with Bluetooth devices where the device is the BlueZ device and iface stays 0 while the IP interface is the actual BNEP link. https://bugzilla.gnome.org/show_bug.cgi?id=782545
2017-05-22 17:04:48 +02:00
nm_device_get_ip_ifindex (self),
device: synchronize IPv6 configuration in stage3 (take 2) Most of the IPv6 methods require a non-tentative link local address configured on the interface; we look at priv->ip6_config to determine if such address exist. If the configuration is out-of-sync, we may proceed with configuration when the link-local address does not exist or is still tentative, especially because we toggle the "disable_ipv6" sysctl parameter just before, which clears all IPv6 addresses on the interface. Ensure that priv->ext_ip6_config_captured is up-to-date before continuing with the IPv6 configuration, and use it to determine whether suitable addresses are present. Fixes test: @ipv6_set_ra_announced_mtu Fixes: 8f4caab60196132c2fd0eb4a444f93f78f130e8e
2017-05-06 10:56:21 +02:00
FALSE,
NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN);
device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941) Support default value for setting 'ipv6.ip6-privacy' in NetworkManager.conf. If the global value is unset, preserve old behavior of looking into /etc/sycctl.conf first. That behavior was introduced with commit d376270bfe673c041e610a981bd6c77c7cb37ba1, since we support ip6-privacy setting. If the global value is set to "unknown", add a new fallback that instead reads the runtime value from "/proc/sys/net/ipv6/conf/default/use_tempaddr" This seems more sensible behavior because we fallback to sysctl, but instead of looking at static files in /etc, read /proc. But to preserve the old behavior, we only do that when a global value is configured at all. https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-04-16 16:38:00 +02:00
ip6_privacy = _ip6_privacy_get (self);
core/rdisc: add support for IPv6 privacy Add support for ipv6-private addresses. This feature needs support from the kernel and libnl. If there is no system support, temporary addresses are not supported. Log a warning in this case. Depending on whether ipv6-privacy (use_tempaddr) is enabled, we add the address flag IFA_F_MANAGETEMPADDR and the kernel will add temporary addresses for us. https://bugzilla.gnome.org/show_bug.cgi?id=705170 https://bugzilla.redhat.com/show_bug.cgi?id=1003859 https://bugzilla.redhat.com/show_bug.cgi?id=1047139 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-03 17:03:35 +01:00
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
if ( strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_AUTO) == 0
|| strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_SHARED) == 0) {
core/rdisc: add support for IPv6 privacy Add support for ipv6-private addresses. This feature needs support from the kernel and libnl. If there is no system support, temporary addresses are not supported. Log a warning in this case. Depending on whether ipv6-privacy (use_tempaddr) is enabled, we add the address flag IFA_F_MANAGETEMPADDR and the kernel will add temporary addresses for us. https://bugzilla.gnome.org/show_bug.cgi?id=705170 https://bugzilla.redhat.com/show_bug.cgi?id=1003859 https://bugzilla.redhat.com/show_bug.cgi?id=1047139 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-01-03 17:03:35 +01:00
if (!addrconf6_start (self, ip6_privacy)) {
core: allow IPv4 to proceed if IPv6 is globally disabled but set to "auto" (rh #1012151) If the user disabled IPv6 support in the kernel with "ipv6.disable=1" on the kernel boot line, then any attempts to open IPv6 sockets (which libndp does) will fail. This failed the entire connection, even if IPv6's "may-fail" property was TRUE. Instead, just fail IPv6 and allow IPv4 to proceed. If IPv4 fails or is disabled, then other logic will fail the entire connection.
2013-10-07 11:40:16 -05:00
/* IPv6 might be disabled; allow IPv4 to proceed */
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
ret = NM_ACT_STAGE_RETURN_IP_FAIL;
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
} else
ret = NM_ACT_STAGE_RETURN_POSTPONE;
core: IPv6 mode link-local must not behave like auto (bgo#706618, bgo#707155) In act_stage3_ip6_config_start, for IPv6 mode link-local, we check if there is already an IPv6 address configured. If yes, we are already done. For now, as current workaround, if the LL does not exist, we NM_ACT_STAGE_RETURN_STOP. Later, we will POSTPONE and wait a timeout until we see a LL address that is no longer TENTATIVE. The same should be done for method auto, so that the device is usable to send router solitations (bgo#707155). https://bugzilla.gnome.org/show_bug.cgi?id=707155 https://bugzilla.gnome.org/show_bug.cgi?id=706618 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-11-07 20:38:08 +01:00
} else if (strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_LINK_LOCAL) == 0) {
ret = linklocal6_start (self);
core: ensure missing IP config settings are treated as "auto" (bgo #699755) Due to recent changes not all settings plugins send an IP config setting when the method is 'auto'. Some old code in the NMDevice IP config paths mishandled this. Fix that up; the expected behavior should be: 1) if the device is a slave, IP configuration is DISABLE/IGNORED 2) if the connection has an IP4 or IP6 setting, use the setting's method 3) default to AUTO
2013-05-07 13:08:33 -05:00
} else if (strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_DHCP) == 0) {
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
priv->dhcp6.mode = NM_NDISC_DHCP_LEVEL_MANAGED;
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
if (!dhcp6_start (self, TRUE)) {
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
/* IPv6 might be disabled; allow IPv4 to proceed */
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
ret = NM_ACT_STAGE_RETURN_IP_FAIL;
dhcp: wait for an IPv6LL address before starting DHCPv6 (bgo #740147) For ipv6.method=dhcp NM was not waiting for an IPv6LL address, which caused the DHCP client to exit early because it had no local address to bind to. https://bugzilla.gnome.org/show_bug.cgi?id=740147
2014-11-14 16:04:44 -06:00
} else
ret = NM_ACT_STAGE_RETURN_POSTPONE;
core: ensure missing IP config settings are treated as "auto" (bgo #699755) Due to recent changes not all settings plugins send an IP config setting when the method is 'auto'. Some old code in the NMDevice IP config paths mishandled this. Fix that up; the expected behavior should be: 1) if the device is a slave, IP configuration is DISABLE/IGNORED 2) if the connection has an IP4 or IP6 setting, use the setting's method 3) default to AUTO
2013-05-07 13:08:33 -05:00
} else if (strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_MANUAL) == 0) {
ip6: fix manual IP config application
2010-04-30 15:49:41 -07:00
ret = NM_ACT_STAGE_RETURN_SUCCESS;
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
} else
_LOGW (LOGD_IP6, "unhandled IPv6 config method '%s'; will fail", method);
ip6: fix manual IP config application
2010-04-30 15:49:41 -07:00
device: only set use_tempaddr sysctl for non-assumed devices and only if the activation stage is not about to fail hard.
2016-08-31 19:11:25 +02:00
if ( ret != NM_ACT_STAGE_RETURN_FAILURE
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
&& !nm_device_sys_iface_state_is_external_or_assume (self)) {
device: only set use_tempaddr sysctl for non-assumed devices and only if the activation stage is not about to fail hard.
2016-08-31 19:11:25 +02:00
switch (ip6_privacy) {
case NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN:
case NM_SETTING_IP6_CONFIG_PRIVACY_DISABLED:
ip6_privacy_str = "0";
break;
case NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_PUBLIC_ADDR:
ip6_privacy_str = "1";
break;
case NM_SETTING_IP6_CONFIG_PRIVACY_PREFER_TEMP_ADDR:
ip6_privacy_str = "2";
break;
}
nm_device_ipv6_sysctl_set (self, "use_tempaddr", ip6_privacy_str);
core: add support for IPv6 Privacy Extensions for SLAAC (RFC4941) (bgo #633233)
2012-02-21 15:44:19 +01:00
}
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
return ret;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
/**
* nm_device_activate_stage3_ip4_start:
* @self: the device
*
* Try starting IPv4 configuration.
*/
gboolean
nm_device_activate_stage3_ip4_start (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMActStageReturn ret;
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NMDeviceStateReason failure_reason = NM_DEVICE_STATE_REASON_NONE;
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
NMIP4Config *ip4_config = NULL;
g_assert (priv->ip4_state == IP_WAIT);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_CONF);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
ret = NM_DEVICE_GET_CLASS (self)->act_stage3_ip4_config_start (self, &ip4_config, &failure_reason);
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
if (ret == NM_ACT_STAGE_RETURN_SUCCESS) {
device: add new result NM_ACT_STAGE_RETURN_IP_DONE for ip config activation This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set the IP state without commiting an NMIP[46]Config instance.
2016-08-31 20:01:12 +02:00
if (!ip4_config)
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
ip4_config = _ip4_config_new (self);
device: add new result NM_ACT_STAGE_RETURN_IP_DONE for ip config activation This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set the IP state without commiting an NMIP[46]Config instance.
2016-08-31 20:01:12 +02:00
nm_device_activate_schedule_ip4_config_result (self, ip4_config);
g_object_unref (ip4_config);
} else if (ret == NM_ACT_STAGE_RETURN_IP_DONE) {
_set_ip_state (self, AF_INET, IP_DONE);
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, FALSE);
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
} else if (ret == NM_ACT_STAGE_RETURN_FAILURE) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, failure_reason);
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
return FALSE;
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
} else if (ret == NM_ACT_STAGE_RETURN_IP_FAIL) {
device: remove unneeded activation-stage result NM_ACT_STAGE_RETURN_FINISH We can express FINISH by returning SUCCESS and not set out_config in act_stage3_ip4_config_start().
2016-08-29 15:33:33 +02:00
/* Activation not wanted */
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_FAIL);
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
} else if (ret == NM_ACT_STAGE_RETURN_IP_WAIT) {
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
/* Wait for something to try IP config again */
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_WAIT);
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
} else
g_assert (ret == NM_ACT_STAGE_RETURN_POSTPONE);
return TRUE;
}
/**
* nm_device_activate_stage3_ip6_start:
* @self: the device
*
* Try starting IPv6 configuration.
*/
gboolean
nm_device_activate_stage3_ip6_start (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMActStageReturn ret;
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NMDeviceStateReason failure_reason = NM_DEVICE_STATE_REASON_NONE;
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
NMIP6Config *ip6_config = NULL;
g_assert (priv->ip6_state == IP_WAIT);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_CONF);
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
ret = NM_DEVICE_GET_CLASS (self)->act_stage3_ip6_config_start (self, &ip6_config, &failure_reason);
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
if (ret == NM_ACT_STAGE_RETURN_SUCCESS) {
device: add new result NM_ACT_STAGE_RETURN_IP_DONE for ip config activation This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set the IP state without commiting an NMIP[46]Config instance.
2016-08-31 20:01:12 +02:00
if (!ip6_config)
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
ip6_config = _ip6_config_new (self);
device: add new result NM_ACT_STAGE_RETURN_IP_DONE for ip config activation This is like NM_ACT_STAGE_RETURN_SUCCESS, except it should only set the IP state without commiting an NMIP[46]Config instance.
2016-08-31 20:01:12 +02:00
/* Here we get a static IPv6 config, like for Shared where it's
* autogenerated or from modems where it comes from ModemManager.
*/
g_warn_if_fail (priv->ac_ip6_config == NULL);
priv->ac_ip6_config = ip6_config;
nm_device_activate_schedule_ip6_config_result (self);
} else if (ret == NM_ACT_STAGE_RETURN_IP_DONE) {
_set_ip_state (self, AF_INET6, IP_DONE);
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, FALSE);
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
} else if (ret == NM_ACT_STAGE_RETURN_FAILURE) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, failure_reason);
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
return FALSE;
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
} else if (ret == NM_ACT_STAGE_RETURN_IP_FAIL) {
device: if there's a ll address already don't re-commit it Configuration commit is an unsafe thing to do for assumed connections, it can remove an externally added address we don't know about yet. The device already has a link-local address; for an assumed connection it's the reason we assumed the method=link-local in the first place.
2015-03-16 19:06:04 +01:00
/* Activation not wanted */
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_FAIL);
device/trivial: rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL and rename NM_ACT_STAGE_RETURN_STOP to NM_ACT_STAGE_RETURN_IP_FAIL. They are only used during IP config stage. Give them a better name.
2016-08-31 18:51:16 +02:00
} else if (ret == NM_ACT_STAGE_RETURN_IP_WAIT) {
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
/* Wait for something to try IP config again */
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_WAIT);
core: allow device subclasses to postpone IPv4 or IPv6 configuration If, for example, a bond interface has dynamic IPv4 configuration and static IPv6 configuration, then without slaves IPv6 config can proceed but IPv4 cannot until a slave is present. Allow subclasses to postpone a specific IP configuration path until they're ready, but let others proceed.
2012-11-15 17:52:24 -06:00
} else
g_assert (ret == NM_ACT_STAGE_RETURN_POSTPONE);
return TRUE;
}
2006-1-3 Dan Williams <dcbw@redhat.com> * src/nm-device-802-11-wireless.c src/nm-device.[ch] - Add hooks to subclasses for stage3_ip_config_start and stage4_ip_config_timeout * src/nm-device-802-3-ethernet.c - (real_get_generic_capabilities): make devices NM-supported by default git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1251 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:47:38 +00:00
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
/*
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
* activate_stage3_ip_config_start
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
* Begin automatic/manual IP configuration
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
*/
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static void
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activate_stage3_ip_config_start (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_WAIT);
_set_ip_state (self, AF_INET6, IP_WAIT);
core: fix the reporting of failed slaves If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
2013-10-21 12:50:58 -04:00
core: add NMActivationStateFlags "layer2-ready", "ip4-ready", and "ip6-ready"
2017-09-26 14:08:27 +02:00
_active_connection_set_state_flags (self,
NM_ACTIVATION_STATE_FLAG_LAYER2_READY);
2008-07-11 Dan Williams <dcbw@redhat.com> Modify the NMDevice::state-changed signal to include the previous state and reason. Enables the applet to provide more information why device activation failed. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3819 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-11 10:28:53 +00:00
nm_device_state_changed (self, NM_DEVICE_STATE_IP_CONFIG, NM_DEVICE_STATE_REASON_NONE);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: don't up devices during IP configuration stages Assumed connections shouldn't require touching the device, and the device should was already set IFF_UP during stage2 (which is skipped for assumed connections). Instead, what the code was really trying to do, was to ensure tha the IP interface the device was going to use was up. The only cases where the IP interface might *not* be up after stage2 is where the IP interface is different than the device's interface, like for Bluetooth, ADSL, WWAN, and PPPoE. Move the call to nm_platform_link_set_up() into nm_device_set_ip_iface() which all those device types will call. Thus, only the device types that really need to up their IP interface will do so, but other devices (including when activating assumed connections) that don't need to do this, won't do it.
2013-11-08 10:58:35 -06:00
/* Device should be up before we can do anything with it */
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_is_up (nm_device_get_platform (self), nm_device_get_ip_ifindex (self)))
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_DEVICE, "interface %s not up for IP configuration", nm_device_get_ip_iface (self));
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
/* IPv4 */
nm-device: only progress with ip-config if the device is still in IP_WAIT The device might be a slave and not need any L3 configuration in which case it will move to IP_DONE: Running test bridge_manipulation_with_1000_slaves ... <debug> [1446834482.545396] [nm-dispatcher.c:304] dispatcher_results_process(): (121) 12-dhcpd succeeded <debug> [1446834482.545404] [nm-dispatcher.c:304] dispatcher_results_process(): (121) 20-chrony succeeded <debug> [1446834482.545481] [devices/nm-device.c:5374] nm_device_activate_stage3_ip_config_start(): [0x7fc77e1c0fc0] (port120): Activation: Stage 3 of 5 (IP Configure Start) started... <info> (port120): device state change: config -> ip-config (reason 'none') [50 70 0] <debug> [1446834482.545578] [devices/nm-device.c:1683] slave_state_changed(): [0x7fc77df77020] (bridge0): slave port120 state change 50 (config) -> 70 (ip-config) <debug> [1446834482.545629] [devices/nm-device.c:7955] nm_device_add_pending_action(): [0x7fc77e1c0fc0] (port120): add_pending_action (2): 'queued state change to secondaries' <debug> [1446834482.545642] [devices/nm-device.c:8806] nm_device_queue_state(): [0x7fc77e1c0fc0] (port120): queued state change to secondaries due to none (id 11380) ** NetworkManager:ERROR:devices/nm-device.c:5250:nm_device_activate_stage3_ip4_start: assertion failed: (priv->ip4_state == IP_WAIT) 5250 g_assert (priv->ip4_state == IP_WAIT); (gdb) print priv->ip4_state $1 = IP_DONE (gdb) print priv->master $3 = { ... master = 0x7fc77df77020, enslaved = 1, master_ready_handled = 1, master_ready_id = 0, is_master = 0, slaves = 0x0, ...}
2015-11-09 11:44:09 +01:00
if ( nm_device_activate_ip4_state_in_wait (self)
&& !nm_device_activate_stage3_ip4_start (self))
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
/* IPv6 */
nm-device: only progress with ip-config if the device is still in IP_WAIT The device might be a slave and not need any L3 configuration in which case it will move to IP_DONE: Running test bridge_manipulation_with_1000_slaves ... <debug> [1446834482.545396] [nm-dispatcher.c:304] dispatcher_results_process(): (121) 12-dhcpd succeeded <debug> [1446834482.545404] [nm-dispatcher.c:304] dispatcher_results_process(): (121) 20-chrony succeeded <debug> [1446834482.545481] [devices/nm-device.c:5374] nm_device_activate_stage3_ip_config_start(): [0x7fc77e1c0fc0] (port120): Activation: Stage 3 of 5 (IP Configure Start) started... <info> (port120): device state change: config -> ip-config (reason 'none') [50 70 0] <debug> [1446834482.545578] [devices/nm-device.c:1683] slave_state_changed(): [0x7fc77df77020] (bridge0): slave port120 state change 50 (config) -> 70 (ip-config) <debug> [1446834482.545629] [devices/nm-device.c:7955] nm_device_add_pending_action(): [0x7fc77e1c0fc0] (port120): add_pending_action (2): 'queued state change to secondaries' <debug> [1446834482.545642] [devices/nm-device.c:8806] nm_device_queue_state(): [0x7fc77e1c0fc0] (port120): queued state change to secondaries due to none (id 11380) ** NetworkManager:ERROR:devices/nm-device.c:5250:nm_device_activate_stage3_ip4_start: assertion failed: (priv->ip4_state == IP_WAIT) 5250 g_assert (priv->ip4_state == IP_WAIT); (gdb) print priv->ip4_state $1 = IP_DONE (gdb) print priv->master $3 = { ... master = 0x7fc77df77020, enslaved = 1, master_ready_handled = 1, master_ready_id = 0, is_master = 0, slaves = 0x0, ...}
2015-11-09 11:44:09 +01:00
if ( nm_device_activate_ip6_state_in_wait (self)
&& !nm_device_activate_stage3_ip6_start (self))
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
/* Proxy */
nm_device_set_proxy_config (self, NULL);
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, TRUE);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
static void
fw_change_zone_cb (NMFirewallManager *firewall_manager,
NMFirewallManagerCallId call_id,
GError *error,
gpointer user_data)
device: refactor setting firewall zone during activation-stage2 schedule_stage3() used to set the firewall before really scheduling the stage3. In that case, fw_change_zone_cb() would then directly call: activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET); This was different from all other places. Usually, only the nm_device_schedule_*() functions would directly call to activation_source_schedule(). Change this, to behave similar as when we wait for master-ready while scheduling stage2. As such, it is more idiomatic, and it would still work correctly even if there were multiple conditions that would block scheduling-stage3.
2015-10-06 17:26:27 +02:00
{
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
NMDevice *self = user_data;
device: refactor setting firewall zone during activation-stage2 schedule_stage3() used to set the firewall before really scheduling the stage3. In that case, fw_change_zone_cb() would then directly call: activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET); This was different from all other places. Usually, only the nm_device_schedule_*() functions would directly call to activation_source_schedule(). Change this, to behave similar as when we wait for master-ready while scheduling stage2. As such, it is more idiomatic, and it would still work correctly even if there were multiple conditions that would block scheduling-stage3.
2015-10-06 17:26:27 +02:00
NMDevicePrivate *priv;
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
device: refactor setting firewall zone during activation-stage2 schedule_stage3() used to set the firewall before really scheduling the stage3. In that case, fw_change_zone_cb() would then directly call: activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET); This was different from all other places. Usually, only the nm_device_schedule_*() functions would directly call to activation_source_schedule(). Change this, to behave similar as when we wait for master-ready while scheduling stage2. As such, it is more idiomatic, and it would still work correctly even if there were multiple conditions that would block scheduling-stage3.
2015-10-06 17:26:27 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
if (priv->fw_call != call_id)
g_return_if_reached ();
device: refactor setting firewall zone during activation-stage2 schedule_stage3() used to set the firewall before really scheduling the stage3. In that case, fw_change_zone_cb() would then directly call: activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET); This was different from all other places. Usually, only the nm_device_schedule_*() functions would directly call to activation_source_schedule(). Change this, to behave similar as when we wait for master-ready while scheduling stage2. As such, it is more idiomatic, and it would still work correctly even if there were multiple conditions that would block scheduling-stage3.
2015-10-06 17:26:27 +02:00
priv->fw_call = NULL;
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
if (nm_utils_error_is_cancelled (error, FALSE))
return;
switch (priv->fw_state) {
case FIREWALL_STATE_WAIT_STAGE_3:
priv->fw_state = FIREWALL_STATE_INITIALIZED;
nm_device_activate_schedule_stage3_ip_config_start (self);
break;
case FIREWALL_STATE_WAIT_IP_CONFIG:
priv->fw_state = FIREWALL_STATE_INITIALIZED;
if (priv->ip4_state == IP_DONE || priv->ip6_state == IP_DONE)
nm_device_start_ip_check (self);
break;
case FIREWALL_STATE_INITIALIZED:
break;
default:
g_return_if_reached ();
}
device: refactor setting firewall zone during activation-stage2 schedule_stage3() used to set the firewall before really scheduling the stage3. In that case, fw_change_zone_cb() would then directly call: activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET); This was different from all other places. Usually, only the nm_device_schedule_*() functions would directly call to activation_source_schedule(). Change this, to behave similar as when we wait for master-ready while scheduling stage2. As such, it is more idiomatic, and it would still work correctly even if there were multiple conditions that would block scheduling-stage3.
2015-10-06 17:26:27 +02:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
firewall: set interface zone before IP configuration (rh #805405) We need to set the interface's firewall zone before we kick off any sort of IP configuration, so that rules for stuff like DHCP are already handled by the time that these services are started.
2012-03-21 15:03:23 -05:00
static void
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
fw_change_zone (NMDevice *self)
firewall: set interface zone before IP configuration (rh #805405) We need to set the interface's firewall zone before we kick off any sort of IP configuration, so that rules for stuff like DHCP are already handled by the time that these services are started.
2012-03-21 15:03:23 -05:00
{
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *applied_connection;
NMSettingConnection *s_con;
firewall: invoke FwAddToZoneFunc callback also when cancelling Not invoking a callback when cancelling the operation is counter intuitive. Note that NMPolicy refs the device, cancelling the call would leave the reference hanging. That was not an issue because the call was never cancelled. But still the behavior of NMFirewallManager is unexpected. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-11-12 14:31:56 +01:00
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
nm_assert (priv->fw_state >= FIREWALL_STATE_INITIALIZED);
firewall: set interface zone before IP configuration (rh #805405) We need to set the interface's firewall zone before we kick off any sort of IP configuration, so that rules for stuff like DHCP are already handled by the time that these services are started.
2012-03-21 15:03:23 -05:00
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
applied_connection = nm_device_get_applied_connection (self);
nm_assert (applied_connection);
firewall: set interface zone before IP configuration (rh #805405) We need to set the interface's firewall zone before we kick off any sort of IP configuration, so that rules for stuff like DHCP are already handled by the time that these services are started.
2012-03-21 15:03:23 -05:00
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
s_con = nm_connection_get_setting_connection (applied_connection);
nm_assert (s_con);
firewall: refactor callback handling in NMFirewallManager Refactor NMFirewallManager to have consistent semantics about asynchronous calls. - the callback is always invoked exactly once, but never synchronously when starting the operation. - while cancelling the request, the callback is invoked synchronously with respect to the cancel operation. - you can cancel a request once (and once only). - you cannot cancel the request once the callback is invoked. - when disposing the object with requests pending, the callbacks are invoked synchronously. - Add a callback argument to nm_firewall_manager_remove_from_zone(). Otherwise, the user never knows whether a call is still pending and cancellable (as complete operations cannot be cancelled). In fact, it makes no sense trying to cancel a call if you don't care about when it completes. - get rid of PENDING_CALL_DUMMY. The dummy callback allows cancellation any number of times. We want to catch wrong usage by asserting that an operation is only cancelled once. - nm_firewall_manager_cancel_call() doesn't need the manager argument. Either the call-id is valid (and has a valid pointer to the manager), or there is a bug and it is a dangling pointer.
2015-09-23 17:18:44 +02:00
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
if (priv->fw_call) {
nm_firewall_manager_cancel_call (priv->fw_call);
nm_assert (!priv->fw_call);
}
firewall: set interface zone before IP configuration (rh #805405) We need to set the interface's firewall zone before we kick off any sort of IP configuration, so that rules for stuff like DHCP are already handled by the time that these services are started.
2012-03-21 15:03:23 -05:00
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
if (G_UNLIKELY (!priv->fw_mgr))
priv->fw_mgr = g_object_ref (nm_firewall_manager_get ());
device: avoid a crash when L3 configuration fails Don't call the IP check until at either IPv4 or IPv6 is actually configured.
2016-10-14 19:57:34 +02:00
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
priv->fw_call = nm_firewall_manager_add_or_change_zone (priv->fw_mgr,
nm_device_get_ip_iface (self),
nm_setting_connection_get_zone (s_con),
FALSE, /* change zone */
fw_change_zone_cb,
self);
firewall: set interface zone before IP configuration (rh #805405) We need to set the interface's firewall zone before we kick off any sort of IP configuration, so that rules for stuff like DHCP are already handled by the time that these services are started.
2012-03-21 15:03:23 -05:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
/*
* nm_device_activate_schedule_stage3_ip_config_start
*
* Schedule IP configuration start
*/
2006-01-07 Dan Williams <dcbw@redhat.com> * src/nm-device-private.h src/nm-device.c - (nm_device_activate_schedule_stage3_ip_config_start): make this function available to subclasses git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1283 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-07 16:22:17 +00:00
void
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
nm_device_activate_schedule_stage3_ip_config_start (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
NMDevicePrivate *priv;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
g_return_if_fail (NM_IS_DEVICE (self));
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
priv = NM_DEVICE_GET_PRIVATE (self);
g_return_if_fail (priv->act_request);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
firewall: set interface zone before IP configuration (rh #805405) We need to set the interface's firewall zone before we kick off any sort of IP configuration, so that rules for stuff like DHCP are already handled by the time that these services are started.
2012-03-21 15:03:23 -05:00
/* Add the interface to the specified firewall zone */
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
if (priv->fw_state == FIREWALL_STATE_UNMANAGED) {
if (!nm_device_sys_iface_state_is_external (self)) {
priv->fw_state = FIREWALL_STATE_WAIT_STAGE_3;
fw_change_zone (self);
device: refactor setting firewall zone during activation-stage2 schedule_stage3() used to set the firewall before really scheduling the stage3. In that case, fw_change_zone_cb() would then directly call: activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET); This was different from all other places. Usually, only the nm_device_schedule_*() functions would directly call to activation_source_schedule(). Change this, to behave similar as when we wait for master-ready while scheduling stage2. As such, it is more idiomatic, and it would still work correctly even if there were multiple conditions that would block scheduling-stage3.
2015-10-06 17:26:27 +02:00
return;
}
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
/* fake success. */
priv->fw_state = FIREWALL_STATE_INITIALIZED;
} else if (priv->fw_state == FIREWALL_STATE_WAIT_STAGE_3) {
/* a firewall call for stage3 is pending. Return and wait. */
return;
firewall: don't set firewall zone for assumed devices https://bugzilla.redhat.com/show_bug.cgi?id=1098281 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-11-13 14:55:47 +01:00
}
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
nm_assert (priv->fw_state == FIREWALL_STATE_INITIALIZED);
device: refactor setting firewall zone during activation-stage2 schedule_stage3() used to set the firewall before really scheduling the stage3. In that case, fw_change_zone_cb() would then directly call: activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET); This was different from all other places. Usually, only the nm_device_schedule_*() functions would directly call to activation_source_schedule(). Change this, to behave similar as when we wait for master-ready while scheduling stage2. As such, it is more idiomatic, and it would still work correctly even if there were multiple conditions that would block scheduling-stage3.
2015-10-06 17:26:27 +02:00
activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
2006-1-3 Dan Williams <dcbw@redhat.com> * src/nm-device-802-11-wireless.c src/nm-device.[ch] - Add hooks to subclasses for stage3_ip_config_start and stage4_ip_config_timeout * src/nm-device-802-3-ethernet.c - (real_get_generic_capabilities): make devices NM-supported by default git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1251 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:47:38 +00:00
static NMActStageReturn
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
act_stage4_ip4_config_timeout (NMDevice *self, NMDeviceStateReason *out_failure_reason)
2006-1-3 Dan Williams <dcbw@redhat.com> * src/nm-device-802-11-wireless.c src/nm-device.[ch] - Add hooks to subclasses for stage3_ip_config_start and stage4_ip_config_timeout * src/nm-device-802-3-ethernet.c - (real_get_generic_capabilities): make devices NM-supported by default git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1251 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:47:38 +00:00
{
device: turn nm_d_ip_config_should_fail to get_ip_config_may_fail Has a cleaner semantics and will be useful later on. Also, make it static -- it's not used outside nm-device.c.
2014-12-11 10:13:59 +01:00
if (!get_ip_config_may_fail (self, AF_INET)) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE);
core: allow selective failure of IP configuration (rh #567978) As long as at least one IP config method completes, and as long as methods that the user required to complete do complete, allow the connection to complete.
2010-05-03 01:19:54 -07:00
return NM_ACT_STAGE_RETURN_FAILURE;
}
return NM_ACT_STAGE_RETURN_SUCCESS;
2006-1-3 Dan Williams <dcbw@redhat.com> * src/nm-device-802-11-wireless.c src/nm-device.[ch] - Add hooks to subclasses for stage3_ip_config_start and stage4_ip_config_timeout * src/nm-device-802-3-ethernet.c - (real_get_generic_capabilities): make devices NM-supported by default git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1251 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2006-01-03 17:47:38 +00:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
/*
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
* nm_device_activate_stage4_ip4_config_timeout
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
* Time out on retrieving the IPv4 config.
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
*/
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static void
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activate_stage4_ip4_config_timeout (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
2007-01-04 Dan Williams <dcbw@redhat.com> Threading removal related cleanups: - Use the glib default main context. Remove the device main context member from NMDevice, and the main_context member from NMData. Change all the idle and timeout scheduler functions to use plain g_idle_add() and g_timeout_add(). - As a side-effect of the first change, nm_dbus_manager_get() no longer takes an argument; fix that up too. - Remove all locking, which is useless since we no longer use threads. For example, nm_get_device_by_iface_locked() has been removed. The global device list lock, the AP List lock, and all static locks in NetworkManagerPolicy.c have been removed. The locking utility functions in NetworkManagerUtils.c have also been removed. - Other cleanups in spacing and code style git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2205 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-01-04 12:06:26 +00:00
NMActStageReturn ret = NM_ACT_STAGE_RETURN_FAILURE;
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NMDeviceStateReason failure_reason = NM_DEVICE_STATE_REASON_NONE;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
ret = NM_DEVICE_GET_CLASS (self)->act_stage4_ip4_config_timeout (self, &failure_reason);
core: allow selective failure of IP configuration (rh #567978) As long as at least one IP config method completes, and as long as methods that the user required to complete do complete, allow the connection to complete.
2010-05-03 01:19:54 -07:00
if (ret == NM_ACT_STAGE_RETURN_POSTPONE)
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
core: allow selective failure of IP configuration (rh #567978) As long as at least one IP config method completes, and as long as methods that the user required to complete do complete, allow the connection to complete.
2010-05-03 01:19:54 -07:00
else if (ret == NM_ACT_STAGE_RETURN_FAILURE) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, failure_reason);
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
g_assert (ret == NM_ACT_STAGE_RETURN_SUCCESS);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_FAIL);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, FALSE);
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
/*
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
* nm_device_activate_schedule_ip4_config_timeout
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
*
* Deal with a timeout of the IPv4 configuration
*
*/
void
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
nm_device_activate_schedule_ip4_config_timeout (NMDevice *self)
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
{
NMDevicePrivate *priv;
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
g_return_if_fail (priv->act_request);
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activation_source_schedule (self, activate_stage4_ip4_config_timeout, AF_INET);
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
static NMActStageReturn
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
act_stage4_ip6_config_timeout (NMDevice *self, NMDeviceStateReason *out_failure_reason)
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
{
device: turn nm_d_ip_config_should_fail to get_ip_config_may_fail Has a cleaner semantics and will be useful later on. Also, make it static -- it's not used outside nm-device.c.
2014-12-11 10:13:59 +01:00
if (!get_ip_config_may_fail (self, AF_INET6)) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE);
core: allow selective failure of IP configuration (rh #567978) As long as at least one IP config method completes, and as long as methods that the user required to complete do complete, allow the connection to complete.
2010-05-03 01:19:54 -07:00
return NM_ACT_STAGE_RETURN_FAILURE;
}
return NM_ACT_STAGE_RETURN_SUCCESS;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
/*
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
* activate_stage4_ip6_config_timeout
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
*
* Time out on retrieving the IPv6 config.
*
*/
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static void
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activate_stage4_ip6_config_timeout (NMDevice *self)
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
{
NMActStageReturn ret = NM_ACT_STAGE_RETURN_FAILURE;
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
NMDeviceStateReason failure_reason = NM_DEVICE_STATE_REASON_NONE;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
ret = NM_DEVICE_GET_CLASS (self)->act_stage4_ip6_config_timeout (self, &failure_reason);
core: allow selective failure of IP configuration (rh #567978) As long as at least one IP config method completes, and as long as methods that the user required to complete do complete, allow the connection to complete.
2010-05-03 01:19:54 -07:00
if (ret == NM_ACT_STAGE_RETURN_POSTPONE)
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
if (ret == NM_ACT_STAGE_RETURN_FAILURE) {
device: rename device-state-reason argument to out_failure_reason This argument is only relevant when the NMActStageReturn argument indicates NM_ACT_STAGE_RETURN_FAILURE. In all other cases it is ignored. Rename the argument to make the meaning clearer. The argument is passed through several layers of code, it isn't obvious that this argument only matters for the failure case. Also, the distinct name makes it easier to distinguish from other uses of the "reason" name. While at it, do some drive-by cleanup: - use g_return_*() instead of g_assert() to have a more graceful assertion. - functions like dhcp4_start() don't need to return a failure reason. Most callers don't care, and the caller who does can determine the proper reason. - allow omitting the out-argument via NM_SET_OUT().
2017-02-22 17:04:00 +01:00
nm_device_state_changed (self, NM_DEVICE_STATE_FAILED, failure_reason);
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
g_assert (ret == NM_ACT_STAGE_RETURN_SUCCESS);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_FAIL);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, FALSE);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
/*
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
* nm_device_activate_schedule_ip6_config_timeout
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
* Deal with a timeout of the IPv6 configuration
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
*
*/
void
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
nm_device_activate_schedule_ip6_config_timeout (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
NMDevicePrivate *priv;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
g_return_if_fail (NM_IS_DEVICE (self));
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-06-11 Tambet Ingo <tambet@ximian.com> * src/nm-device.c: Make the activation stage virtual functions take NMDevice argument. The activation request is easy to retrieve. * src/nm-activation-request.c: Convert to GObject. Do not include half of NM headers just to be a convenient location for devices to store random stuff. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2587 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-11 13:36:34 +00:00
priv = NM_DEVICE_GET_PRIVATE (self);
g_return_if_fail (priv->act_request);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activation_source_schedule (self, activate_stage4_ip6_config_timeout, AF_INET6);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
static gboolean
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
share_init (NMDevice *self)
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
{
char *modules[] = { "ip_tables", "iptable_nat", "nf_nat_ftp", "nf_nat_irc",
"nf_nat_sip", "nf_nat_tftp", "nf_nat_pptp", "nf_nat_h323",
NULL };
char **iter;
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
int errsv;
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_sysctl_set (nm_device_get_platform (self), NMP_SYSCTL_PATHID_ABSOLUTE ("/proc/sys/net/ipv4/ip_forward"), "1")) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
errsv = errno;
device: don't fail the device if IPv4 forwarding fails Just fail the IPv4 method. Plus improve some comments.
2016-11-05 18:31:13 +01:00
nm_log_err (LOGD_SHARING, "share: error enabling IPv4 forwarding: (%d) %s",
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
errsv, strerror (errsv));
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
return FALSE;
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
}
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_sysctl_set (nm_device_get_platform (self), NMP_SYSCTL_PATHID_ABSOLUTE ("/proc/sys/net/ipv4/ip_dynaddr"), "1")) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
errsv = errno;
device: don't fail the device if IPv4 forwarding fails Just fail the IPv4 method. Plus improve some comments.
2016-11-05 18:31:13 +01:00
nm_log_err (LOGD_SHARING, "share: error enabling dynamic addresses: (%d) %s",
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
errsv, strerror (errsv));
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
}
core: use nm_utils_modprobe() https://bugzilla.gnome.org/show_bug.cgi?id=740651
2015-01-09 11:49:25 +01:00
for (iter = modules; *iter; iter++)
core: add option to suppress error logging if nm_utils_modprobe() fails We don't want error logging for nm_platform_link_add() which tries to load the bonding module. Later we will run tests as non-root, where modprobe will fail. Logging an error would break the tests.
2015-05-18 17:37:05 +02:00
nm_utils_modprobe (NULL, FALSE, *iter, NULL);
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
return TRUE;
}
build: avoid compiler warnings about non-constant format strings (-Wformat-nonliteral)
2016-06-05 11:46:06 +02:00
#define add_share_rule(req, table, ...) \
G_STMT_START { \
char *_cmd = g_strdup_printf (__VA_ARGS__); \
nm_act_request_add_share_rule (req, table, _cmd); \
g_free (_cmd); \
} G_STMT_END
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
static gboolean
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
start_sharing (NMDevice *self, NMIP4Config *config)
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMActRequest *req;
GError *error = NULL;
char str_addr[INET_ADDRSTRLEN + 1];
char str_mask[INET_ADDRSTRLEN + 1];
guint32 netmask, network;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
const NMPlatformIP4Address *ip4_addr = NULL;
2008-10-22 Dan Williams <dcbw@redhat.com> * src/NetworkManagerSystem.c src/nm-device.c - Use the device's IP interface where appropriate (Per Hallsmark) git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4206 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-10-22 16:32:13 +00:00
const char *ip_iface;
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
g_return_val_if_fail (config != NULL, FALSE);
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
ip_iface = nm_device_get_ip_iface (self);
device: avoid touching sysctls for devices without platform link Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to cunstruct sysctl paths and it is way less tolerant towards using something that is not an interface name in the path. It's always been incorrect to assume the ifname is a linux link name and it resulted it ugly, if benign, sysctl access attempts such as "/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc. Now it triggers an assertion failure. Let's guard all such accesses. Fixes: 32b3eb1181 Fixes: cd271d5cb1
2017-10-31 18:22:37 +01:00
if (!ip_iface)
return FALSE;
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
ip4_addr = nm_ip4_config_get_first_address (config);
device: fix address check in start_sharing() Fixes: 22edeb5b691befd796c534cf71901b32f0b7945b
2017-07-25 14:45:08 +02:00
if (!ip4_addr || !ip4_addr->address)
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
return FALSE;
all: use _nm_utils_ip4_*() utils functions
2017-09-05 15:25:34 +02:00
netmask = _nm_utils_ip4_prefix_to_netmask (ip4_addr->plen);
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
if (!inet_ntop (AF_INET, &netmask, str_mask, sizeof (str_mask)))
return FALSE;
core: switch nm-ip4-config's NMIP[46]Address to NMPlatformIP[46]Address
2013-06-29 13:33:36 +02:00
network = ip4_addr->address & netmask;
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
if (!inet_ntop (AF_INET, &network, str_addr, sizeof (str_addr)))
return FALSE;
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!share_init (self))
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
return FALSE;
req = nm_device_get_act_request (self);
g_assert (req);
sharing: fix handling of rule negation (debian #638995) ! after the option is deprecated at least as far back as iptables 1.4.12 on 2.6.32. ! should be before the option instead. Reported-by: Ralf Jung <ralfjung-e@gmx.de>
2011-09-06 18:31:40 -05:00
add_share_rule (req, "nat", "POSTROUTING --source %s/%s ! --destination %s/%s --jump MASQUERADE", str_addr, str_mask, str_addr, str_mask);
core: list iptables sharing rules in the right order The rules were added to the list using g_slist_append() and then applied one at time using "iptables --insert" which puts them at the beginning of the chain, reversing the initial order. Instead, list them in the desired order and use g_slist_prepend() to achieve the same result. This has no functional changes.
2016-01-21 16:39:55 +01:00
add_share_rule (req, "filter", "FORWARD --destination %s/%s --out-interface %s --match state --state ESTABLISHED,RELATED --jump ACCEPT", str_addr, str_mask, ip_iface);
add_share_rule (req, "filter", "FORWARD --source %s/%s --in-interface %s --jump ACCEPT", str_addr, str_mask, ip_iface);
add_share_rule (req, "filter", "FORWARD --in-interface %s --out-interface %s --jump ACCEPT", ip_iface, ip_iface);
add_share_rule (req, "filter", "FORWARD --out-interface %s --jump REJECT", ip_iface);
add_share_rule (req, "filter", "FORWARD --in-interface %s --jump REJECT", ip_iface);
add_share_rule (req, "filter", "INPUT --in-interface %s --protocol udp --destination-port 67 --jump ACCEPT", ip_iface);
add_share_rule (req, "filter", "INPUT --in-interface %s --protocol tcp --destination-port 67 --jump ACCEPT", ip_iface);
add_share_rule (req, "filter", "INPUT --in-interface %s --protocol udp --destination-port 53 --jump ACCEPT", ip_iface);
add_share_rule (req, "filter", "INPUT --in-interface %s --protocol tcp --destination-port 53 --jump ACCEPT", ip_iface);
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
nm_act_request_set_shared (req, TRUE);
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
if (!nm_dnsmasq_manager_start (priv->dnsmasq_manager, config, &error)) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGE (LOGD_SHARING, "share: (%s) failed to start dnsmasq: %s",
all: clean-up usage of GError Functions that take a GError** MUST fill it in on error. There is no need to check whether error is NULL if the function it was passed to had a failing return value. Likewise, a proper GError must have a non-NULL message, so there's no need to double-check that either. Based-on-patch-by: Dan Winship <danw@gnome.org>
2016-02-28 16:25:36 +01:00
ip_iface, error->message);
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
g_error_free (error);
nm_act_request_set_shared (req, FALSE);
return FALSE;
}
core: use define for NMDnsMasqManager's "state-changed" signal name
2015-12-07 19:45:34 +01:00
priv->dnsmasq_state_id = g_signal_connect (priv->dnsmasq_manager, NM_DNS_MASQ_MANAGER_STATE_CHANGED,
2008-08-15 Dan Williams <dcbw@redhat.com> Do connection sharing in a cleaner manner; all required iptables rules are now stored in the activation request and pertain only to the device which is being shared to other computers. * src/nm-activation-request.c src/nm-activation-request.h - (nm_act_request_add_share_rule): new function; add a sharing rule to the activation request which will get torn down automatically when the activation request dies - (nm_act_request_set_shared): push sharing rules to iptables when sharing is started, and tear them down when sharing is stopped * src/nm-device.c - (start_sharing): start up sharing by doing the required iptables magic - (share_init): poke the right bits of the kernel and load the right modules for NAT - (nm_device_activate_stage5_ip_config_commit): start NAT-ing this connection if it's a 'shared' connection * src/NetworkManagerPolicy.c - Remove all sharing stuff; done in the device code itself git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3969 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-15 15:34:28 +00:00
G_CALLBACK (dnsmasq_state_changed_cb),
self);
return TRUE;
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
devices: send ARPs when configuring static IPv4 addresses (rh #1073447) After applying a configuration with static IPv4 addresses, call /sbin/arping to announce the new addresses to the host's neighbors. (Basic idea copied from Fedora ifup-eth.)
2014-03-19 12:39:38 -04:00
static void
arp_cleanup (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
if (priv->arping.announcing) {
nm_arping_manager_destroy (priv->arping.announcing);
priv->arping.announcing = NULL;
}
devices: send ARPs when configuring static IPv4 addresses (rh #1073447) After applying a configuration with static IPv4 addresses, call /sbin/arping to announce the new addresses to the host's neighbors. (Basic idea copied from Fedora ifup-eth.)
2014-03-19 12:39:38 -04:00
}
static void
arp_announce (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
NMSettingIPConfig *s_ip4;
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
guint num, i;
const guint8 *hw_addr;
size_t hw_addr_len = 0;
devices: send ARPs when configuring static IPv4 addresses (rh #1073447) After applying a configuration with static IPv4 addresses, call /sbin/arping to announce the new addresses to the host's neighbors. (Basic idea copied from Fedora ifup-eth.)
2014-03-19 12:39:38 -04:00
arp_cleanup (self);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
hw_addr = nm_platform_link_get_address (nm_device_get_platform (self),
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
nm_device_get_ip_ifindex (self),
&hw_addr_len);
if (!hw_addr_len || !hw_addr)
return;
devices: send ARPs when configuring static IPv4 addresses (rh #1073447) After applying a configuration with static IPv4 addresses, call /sbin/arping to announce the new addresses to the host's neighbors. (Basic idea copied from Fedora ifup-eth.)
2014-03-19 12:39:38 -04:00
/* We only care about manually-configured addresses; DHCP- and autoip-configured
* ones should already have been seen on the network at this point.
*/
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
devices: send ARPs when configuring static IPv4 addresses (rh #1073447) After applying a configuration with static IPv4 addresses, call /sbin/arping to announce the new addresses to the host's neighbors. (Basic idea copied from Fedora ifup-eth.)
2014-03-19 12:39:38 -04:00
if (!connection)
return;
s_ip4 = nm_connection_get_setting_ip4_config (connection);
if (!s_ip4)
return;
libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes Split a base NMSettingIPConfig class out of NMSettingIP4Config and NMSettingIP6Config, and update things accordingly. Further simplifications of now-redundant IPv4-vs-IPv6 code are possible, and should happen in the future.
2014-10-19 17:30:10 -04:00
num = nm_setting_ip_config_get_num_addresses (s_ip4);
devices: send ARPs when configuring static IPv4 addresses (rh #1073447) After applying a configuration with static IPv4 addresses, call /sbin/arping to announce the new addresses to the host's neighbors. (Basic idea copied from Fedora ifup-eth.)
2014-03-19 12:39:38 -04:00
if (num == 0)
return;
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
priv->arping.announcing = nm_arping_manager_new (nm_device_get_ip_ifindex (self));
for (i = 0; i < num; i++) {
NMIPAddress *ip = nm_setting_ip_config_get_address (s_ip4, i);
in_addr_t addr;
if (inet_pton (AF_INET, nm_ip_address_get_address (ip), &addr) == 1)
nm_arping_manager_add_address (priv->arping.announcing, addr);
else
g_warn_if_reached ();
}
nm_arping_manager_announce_addresses (priv->arping.announcing);
devices: send ARPs when configuring static IPv4 addresses (rh #1073447) After applying a configuration with static IPv4 addresses, call /sbin/arping to announce the new addresses to the host's neighbors. (Basic idea copied from Fedora ifup-eth.)
2014-03-19 12:39:38 -04:00
}
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static void
device: rename activate_stage5_ip4_config_commit() to activate_stage5_ip4_config_result() We have nm_device_activate_schedule_ip4_config_result(). The name should match. Note, this affects logging, as we log the function name.
2017-06-01 21:50:40 +02:00
activate_stage5_ip4_config_result (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
core: implement connection assumption Mark activation requests that contain connections to be assumed, and use that to short-circuit various parts of the activation process by not touching various device attributes, since they are already set up. Also ensure the device is not deactivated when it initially becomes managed, because that would kill the connection we are about to assume.
2009-08-05 18:03:09 -04:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
NMActRequest *req;
core: cleanup getting iface for NMDevice for logging Since refactoring logging, these calls are not needed. Just forgot to remove them. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-02 00:48:35 +02:00
const char *method;
2008-05-29 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (dnsmasq_state_changed_cb): new function; fail the connection if something happens to dnsmasq - (nm_device_new_ip4_shared_config): new function; create a new ip4-config for shared connections. Shared connections always use a fixed static IP address. - (real_act_stage4_get_ip4_config): handle shared connections; fix autoip connections by actually using the returned ip4-config and not leaking it - (nm_device_activate_stage5_ip_config_commit): start dnsmasq for shared connections - (nm_device_deactivate_quickly, nm_device_dispose): terminate dnsmasq if its active git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3711 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-29 20:58:52 +00:00
NMConnection *connection;
core: ensure interface is up before applying IP configuration (bgo #738479) Routing configuration fails to apply if the device is not IFF_UP, so if we're going to apply IP configuration to the device, make sure it's IFF_UP first. https://bugzilla.gnome.org/show_bug.cgi?id=738479
2014-10-13 15:10:20 -05:00
int ip_ifindex;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
req = nm_device_get_act_request (self);
g_assert (req);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_act_request_get_applied_connection (req);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
g_assert (connection);
core: ensure interface is up before applying IP configuration (bgo #738479) Routing configuration fails to apply if the device is not IFF_UP, so if we're going to apply IP configuration to the device, make sure it's IFF_UP first. https://bugzilla.gnome.org/show_bug.cgi?id=738479
2014-10-13 15:10:20 -05:00
/* Interface must be IFF_UP before IP config can be applied */
ip_ifindex = nm_device_get_ip_ifindex (self);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_is_up (nm_device_get_platform (self), ip_ifindex) && !nm_device_sys_iface_state_is_external_or_assume (self)) {
nm_platform_link_set_up (nm_device_get_platform (self), ip_ifindex, NULL);
if (!nm_platform_link_is_up (nm_device_get_platform (self), ip_ifindex))
core: ensure interface is up before applying IP configuration (bgo #738479) Routing configuration fails to apply if the device is not IFF_UP, so if we're going to apply IP configuration to the device, make sure it's IFF_UP first. https://bugzilla.gnome.org/show_bug.cgi?id=738479
2014-10-13 15:10:20 -05:00
_LOGW (LOGD_DEVICE, "interface %s not up for IP configuration", nm_device_get_ip_iface (self));
}
core: implement connection assumption Mark activation requests that contain connections to be assumed, and use that to short-circuit various parts of the activation process by not touching various device attributes, since they are already set up. Also ensure the device is not deactivated when it initially becomes managed, because that would kill the connection we are about to assume.
2009-08-05 18:03:09 -04:00
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
/* NULL to use the existing priv->dev_ip4_config */
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
if (!ip4_config_merge_and_apply (self, TRUE)) {
device/logging: downgrade log level of "Activation: Stage x of 5" messages Only downgrade the <info> levels to <debug>. Leave warnings unchanged. https://bugzilla.redhat.com/show_bug.cgi?id=1212196
2015-04-17 15:56:04 +02:00
_LOGD (LOGD_DEVICE | LOGD_IP4, "Activation: Stage 5 of 5 (IPv4 Commit) failed");
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_CONFIG_FAILED);
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
2008-05-29 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (dnsmasq_state_changed_cb): new function; fail the connection if something happens to dnsmasq - (nm_device_new_ip4_shared_config): new function; create a new ip4-config for shared connections. Shared connections always use a fixed static IP address. - (real_act_stage4_get_ip4_config): handle shared connections; fix autoip connections by actually using the returned ip4-config and not leaking it - (nm_device_activate_stage5_ip_config_commit): start dnsmasq for shared connections - (nm_device_deactivate_quickly, nm_device_dispose): terminate dnsmasq if its active git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3711 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-29 20:58:52 +00:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
/* Start IPv4 sharing if we need it */
core: don't have IP4 and IP6 configs on slaves Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
2013-10-14 10:38:56 -04:00
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP4_CONFIG);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
settings: make connections always have s_ip4 and s_ip6 Make sure that all connections returned from NMSettings or created via AddAndActivateConnection have an NMSettingIP4Config and an NMSettingIP6Config, with non-NULL methods, and get rid of now-unnecessary checks for those. Also move the slaves-can't-have-IP-config checks into the platform-independent code as well. This also gets rid of spurious "ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a slave ifcfg file. Partly based on a patch from Pavel. https://bugzilla.gnome.org/show_bug.cgi?id=708875
2013-09-26 17:34:23 -04:00
if (strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_SHARED) == 0) {
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
if (!start_sharing (self, priv->ip4_config)) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_SHARING, "Activation: Stage 5 of 5 (IPv4 Commit) start sharing failed.");
device: don't fail the device if IPv4 forwarding fails Just fail the IPv4 method. Plus improve some comments.
2016-11-05 18:31:13 +01:00
nm_device_ip_method_failed (self, AF_INET, NM_DEVICE_STATE_REASON_SHARED_START_FAILED);
device/logging: refactor logging for activation-stage Instead of adding explicit logging lines while scheduling and processing the activation-stages, only log them in activation_source_schedule() and activation_source_handle_cb(). Effectively, lines like: "Activation: Stage 1 of 5 (Device Prepare) started..." are now: "activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
2015-10-06 14:27:03 +02:00
return;
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
}
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
core: emit dhcp4/dhcp6-change dispatcher events if other IP completes first (rh #1091296) (bgo #729284) If IPv6 completes first it would emit the "up" dispatcher event with IPv6 details and move the device to ACTIVATED state. But if DHCPv4 was still running, no dispatcher event would be emitted with the DHCPv4 information until the first lease renew. Thus dispatcher scripts would not receive DHCPv4 information for quite some time. Ensure that if the other IP version completes first, that when the slower method's DHCP completes, that it emits the appropriate dhcp4-change or dhcp6-change event so that dispatcher scripts get the information as soon as it's available. https://bugzilla.gnome.org/show_bug.cgi?id=729284
2014-04-29 16:42:57 -05:00
/* If IPv4 wasn't the first to complete, and DHCP was used, then ensure
* dispatcher scripts get the DHCP lease information.
*/
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
if ( priv->dhcp4.client
core: emit dhcp4/dhcp6-change dispatcher events if other IP completes first (rh #1091296) (bgo #729284) If IPv6 completes first it would emit the "up" dispatcher event with IPv6 details and move the device to ACTIVATED state. But if DHCPv4 was still running, no dispatcher event would be emitted with the DHCPv4 information until the first lease renew. Thus dispatcher scripts would not receive DHCPv4 information for quite some time. Ensure that if the other IP version completes first, that when the slower method's DHCP completes, that it emits the appropriate dhcp4-change or dhcp6-change event so that dispatcher scripts get the information as soon as it's available. https://bugzilla.gnome.org/show_bug.cgi?id=729284
2014-04-29 16:42:57 -05:00
&& nm_device_activate_ip4_state_in_conf (self)
&& (nm_device_get_state (self) > NM_DEVICE_STATE_IP_CONFIG)) {
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
nm_dispatcher_call_device (NM_DISPATCHER_ACTION_DHCP4_CHANGE,
self,
NULL,
NULL, NULL, NULL);
core: emit dhcp4/dhcp6-change dispatcher events if other IP completes first (rh #1091296) (bgo #729284) If IPv6 completes first it would emit the "up" dispatcher event with IPv6 details and move the device to ACTIVATED state. But if DHCPv4 was still running, no dispatcher event would be emitted with the DHCPv4 information until the first lease renew. Thus dispatcher scripts would not receive DHCPv4 information for quite some time. Ensure that if the other IP version completes first, that when the slower method's DHCP completes, that it emits the appropriate dhcp4-change or dhcp6-change event so that dispatcher scripts get the information as soon as it's available. https://bugzilla.gnome.org/show_bug.cgi?id=729284
2014-04-29 16:42:57 -05:00
}
devices: send ARPs when configuring static IPv4 addresses (rh #1073447) After applying a configuration with static IPv4 addresses, call /sbin/arping to announce the new addresses to the host's neighbors. (Basic idea copied from Fedora ifup-eth.)
2014-03-19 12:39:38 -04:00
arp_announce (self);
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_remove_pending_action (self, NM_PENDING_ACTION_DHCP4, FALSE);
core: wait with "startup complete" for both IPv4 and IPv6 dynamic configuration In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until both IPv4 and IPv6 are ready. This especially has an effect on nm-online/NetworkManager-wait-online.service, which blocks until configuration of both IPv4 and IPv6 is ready. We queue a pending_action when automatic configuration starts and remove it again, when we receive an address. Before, "startup complete" was reached when either one of the two IP protocols was configured. https://bugzilla.redhat.com/show_bug.cgi?id=1086906 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-14 17:57:56 +02:00
device: check may_fail when progressing to IP_CHECK Don't let the device progress to check and then in turn to activated unless all the required IP configuration is in place.
2016-02-24 13:12:24 +01:00
/* Enter the IP_CHECK state if this is the first method to complete */
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_DONE);
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, FALSE);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
}
void
nm_device_activate_schedule_ip4_config_result (NMDevice *self, NMIP4Config *config)
{
NMDevicePrivate *priv;
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
g_clear_object (&priv->dev_ip4_config);
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
if (config)
priv->dev_ip4_config = g_object_ref (config);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
device: rename activate_stage5_ip4_config_commit() to activate_stage5_ip4_config_result() We have nm_device_activate_schedule_ip4_config_result(). The name should match. Note, this affects logging, as we log the function name.
2017-06-01 21:50:40 +02:00
activation_source_schedule (self, activate_stage5_ip4_config_result, AF_INET);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
}
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
gboolean
nm_device_activate_ip4_state_in_conf (NMDevice *self)
{
g_return_val_if_fail (self != NULL, FALSE);
return NM_DEVICE_GET_PRIVATE (self)->ip4_state == IP_CONF;
}
core: expose IP4 wait state to subclasses We'll need to this to determine whether or not to retry IP config from device subclasses.
2013-01-28 13:34:44 -06:00
gboolean
nm_device_activate_ip4_state_in_wait (NMDevice *self)
{
g_return_val_if_fail (self != NULL, FALSE);
return NM_DEVICE_GET_PRIVATE (self)->ip4_state == IP_WAIT;
}
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
gboolean
nm_device_activate_ip4_state_done (NMDevice *self)
{
g_return_val_if_fail (self != NULL, FALSE);
return NM_DEVICE_GET_PRIVATE (self)->ip4_state == IP_DONE;
}
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
/*
* Returns a NMIP6Config containing NM-configured addresses which
* have the tentative flag, or NULL if none is present.
*/
static NMIP6Config *
dad6_get_pending_addresses (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMIP6Config *confs[] = { priv->ac_ip6_config,
priv->dhcp6.ip6_config,
priv->con_ip6_config,
priv->wwan_ip6_config };
const NMPlatformIP6Address *addr, *pl_addr;
NMIP6Config *dad6_config = NULL;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
NMDedupMultiIter ipconf_iter;
guint i;
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
int ifindex;
ifindex = nm_device_get_ip_ifindex (self);
g_return_val_if_fail (ifindex > 0, NULL);
/* We are interested only in addresses that we have explicitly configured,
* not in externally added ones.
*/
for (i = 0; i < G_N_ELEMENTS (confs); i++) {
if (confs[i]) {
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
nm_ip_config_iter_ip6_address_for_each (&ipconf_iter, confs[i], &addr) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
pl_addr = nm_platform_ip6_address_get (nm_device_get_platform (self),
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
ifindex,
platform: remove plen argument for IPv6 address ID The prefix length is not part of the ID for IPv6 address. Remove it from nmp_object_stackinit_id_ip6_address().
2017-05-26 21:49:00 +02:00
addr->address);
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
if ( pl_addr
&& NM_FLAGS_HAS (pl_addr->n_ifa_flags, IFA_F_TENTATIVE)
&& !NM_FLAGS_HAS (pl_addr->n_ifa_flags, IFA_F_DADFAILED)
&& !NM_FLAGS_HAS (pl_addr->n_ifa_flags, IFA_F_OPTIMISTIC)) {
_LOGt (LOGD_DEVICE, "IPv6 DAD: pending address %s",
nm_platform_ip6_address_to_string (pl_addr, NULL, 0));
if (!dad6_config)
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
dad6_config = _ip6_config_new (self);
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
nm_ip6_config_add_address (dad6_config, pl_addr);
}
}
}
}
return dad6_config;
}
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static void
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activate_stage5_ip6_config_commit (NMDevice *self)
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMActRequest *req;
device: enable the IPv6 forwarding for shared connections Useful when they have internet-routable prefixes, consistent with IPv4.
2016-11-05 18:31:20 +01:00
const char *method;
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
NMConnection *connection;
core: ensure interface is up before applying IP configuration (bgo #738479) Routing configuration fails to apply if the device is not IFF_UP, so if we're going to apply IP configuration to the device, make sure it's IFF_UP first. https://bugzilla.gnome.org/show_bug.cgi?id=738479
2014-10-13 15:10:20 -05:00
int ip_ifindex;
device: enable the IPv6 forwarding for shared connections Useful when they have internet-routable prefixes, consistent with IPv4.
2016-11-05 18:31:20 +01:00
int errsv;
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
req = nm_device_get_act_request (self);
g_assert (req);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_act_request_get_applied_connection (req);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
g_assert (connection);
core: ensure interface is up before applying IP configuration (bgo #738479) Routing configuration fails to apply if the device is not IFF_UP, so if we're going to apply IP configuration to the device, make sure it's IFF_UP first. https://bugzilla.gnome.org/show_bug.cgi?id=738479
2014-10-13 15:10:20 -05:00
/* Interface must be IFF_UP before IP config can be applied */
ip_ifindex = nm_device_get_ip_ifindex (self);
device: avoid touching sysctls for devices without platform link Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to cunstruct sysctl paths and it is way less tolerant towards using something that is not an interface name in the path. It's always been incorrect to assume the ifname is a linux link name and it resulted it ugly, if benign, sysctl access attempts such as "/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc. Now it triggers an assertion failure. Let's guard all such accesses. Fixes: 32b3eb1181 Fixes: cd271d5cb1
2017-10-31 18:22:37 +01:00
g_return_if_fail (ip_ifindex);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_is_up (nm_device_get_platform (self), ip_ifindex) && !nm_device_sys_iface_state_is_external_or_assume (self)) {
nm_platform_link_set_up (nm_device_get_platform (self), ip_ifindex, NULL);
if (!nm_platform_link_is_up (nm_device_get_platform (self), ip_ifindex))
core: ensure interface is up before applying IP configuration (bgo #738479) Routing configuration fails to apply if the device is not IFF_UP, so if we're going to apply IP configuration to the device, make sure it's IFF_UP first. https://bugzilla.gnome.org/show_bug.cgi?id=738479
2014-10-13 15:10:20 -05:00
_LOGW (LOGD_DEVICE, "interface %s not up for IP configuration", nm_device_get_ip_iface (self));
}
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (ip6_config_merge_and_apply (self, TRUE)) {
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
if ( priv->dhcp6.mode != NM_NDISC_DHCP_LEVEL_NONE
device: don't progress to ip-check if the DHCPv6 is still pending
2016-01-14 20:39:33 +01:00
&& priv->ip6_state == IP_CONF) {
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
if (priv->dhcp6.ip6_config) {
device: don't progress to ip-check if the DHCPv6 is still pending
2016-01-14 20:39:33 +01:00
/* If IPv6 wasn't the first IP to complete, and DHCP was used,
* then ensure dispatcher scripts get the DHCP lease information.
*/
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
nm_dispatcher_call_device (NM_DISPATCHER_ACTION_DHCP6_CHANGE,
self,
NULL,
NULL, NULL, NULL);
device: don't progress to ip-check if the DHCPv6 is still pending
2016-01-14 20:39:33 +01:00
} else {
/* still waiting for first dhcp6 lease. */
return;
}
core: emit dhcp4/dhcp6-change dispatcher events if other IP completes first (rh #1091296) (bgo #729284) If IPv6 completes first it would emit the "up" dispatcher event with IPv6 details and move the device to ACTIVATED state. But if DHCPv4 was still running, no dispatcher event would be emitted with the DHCPv4 information until the first lease renew. Thus dispatcher scripts would not receive DHCPv4 information for quite some time. Ensure that if the other IP version completes first, that when the slower method's DHCP completes, that it emits the appropriate dhcp4-change or dhcp6-change event so that dispatcher scripts get the information as soon as it's available. https://bugzilla.gnome.org/show_bug.cgi?id=729284
2014-04-29 16:42:57 -05:00
}
device: refactor pending-action strings as named defines
2017-01-27 13:57:15 +01:00
nm_device_remove_pending_action (self, NM_PENDING_ACTION_DHCP6, FALSE);
nm_device_remove_pending_action (self, NM_PENDING_ACTION_AUTOCONF6, FALSE);
core: wait with "startup complete" for both IPv4 and IPv6 dynamic configuration In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until both IPv4 and IPv6 are ready. This especially has an effect on nm-online/NetworkManager-wait-online.service, which blocks until configuration of both IPv4 and IPv6 is ready. We queue a pending_action when automatic configuration starts and remove it again, when we receive an address. Before, "startup complete" was reached when either one of the two IP protocols was configured. https://bugzilla.redhat.com/show_bug.cgi?id=1086906 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-14 17:57:56 +02:00
device: enable the IPv6 forwarding for shared connections Useful when they have internet-routable prefixes, consistent with IPv4.
2016-11-05 18:31:20 +01:00
/* Start IPv6 forwarding if we need it */
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG);
policy: make dispose() reentrant and indention
2016-11-09 17:58:11 +01:00
device: enable the IPv6 forwarding for shared connections Useful when they have internet-routable prefixes, consistent with IPv4.
2016-11-05 18:31:20 +01:00
if (strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_SHARED) == 0) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_sysctl_set (nm_device_get_platform (self), NMP_SYSCTL_PATHID_ABSOLUTE ("/proc/sys/net/ipv6/conf/all/forwarding"), "1")) {
device: enable the IPv6 forwarding for shared connections Useful when they have internet-routable prefixes, consistent with IPv4.
2016-11-05 18:31:20 +01:00
errsv = errno;
_LOGE (LOGD_SHARING, "share: error enabling IPv6 forwarding: (%d) %s", errsv, strerror (errsv));
nm_device_ip_method_failed (self, AF_INET6, NM_DEVICE_STATE_REASON_SHARED_START_FAILED);
}
}
policy: make dispose() reentrant and indention
2016-11-09 17:58:11 +01:00
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
/* Check if we have to wait for DAD */
if (priv->ip6_state == IP_CONF && !priv->dad6_ip6_config) {
device: don't await for IPv6 DAD to finish if we are ignoring that there's no carrier It's not the correct thing to do, but is the same behavior we've done previously. DAD is not even going to start until there's carrier and the client would just wait indefinitely. Ideally, the client would choose not to waiat, but it currently there's no way the client would discover what is going on. https://bugzilla.redhat.com/show_bug.cgi?id=1446367
2017-04-30 17:30:44 +02:00
if (!priv->carrier && priv->ignore_carrier && get_ip_config_may_fail (self, AF_INET6))
_LOGI (LOGD_DEVICE | LOGD_IP6, "IPv6 DAD: carrier missing and ignored, not delaying activation");
else
priv->dad6_ip6_config = dad6_get_pending_addresses (self);
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
if (priv->dad6_ip6_config) {
device: don't await for IPv6 DAD to finish if we are ignoring that there's no carrier It's not the correct thing to do, but is the same behavior we've done previously. DAD is not even going to start until there's carrier and the client would just wait indefinitely. Ideally, the client would choose not to waiat, but it currently there's no way the client would discover what is going on. https://bugzilla.redhat.com/show_bug.cgi?id=1446367
2017-04-30 17:30:44 +02:00
_LOGD (LOGD_DEVICE | LOGD_IP6, "IPv6 DAD: awaiting termination");
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
} else {
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_DONE);
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, FALSE);
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
}
}
core: combine DHCP and RA IPv6 configs when either changes Since both RA and DHCP may be run at the same time, we want to make sure to merge both configs into a final config when either RA or DHCP changes. Previously this only happened when RA changed, but not when DHCP changed or completed. This caused the config applied when DHCP completed to not contain the RA-derived address, which was then removed from the device, which then regressed the IPv6 RA state, causing a device failure. Found by Tore Anderson Oct 18 18:35:00 wrath dhclient[13782]: RCV: Reply message on eth0 from fe80::ca6c:87ff:feab:da5f. Oct 18 18:35:00 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 state changed nbi -> renew6 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642273] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 7 Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642282] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'interface'=>'eth0' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642288] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_client_id'=>'0:3:0:1:0:30:1b:bc:7f:23' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642294] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'reason'=>'RENEW6' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642300] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_name_servers'=>'2001:840:100:: 2001:840:200::' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642305] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'new_dhcp6_server_id'=>'0:3:0:1:c8:6c:87:ab:da:5f' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.642311] [nm-dhcp-client.c:1211] ip6_options_to_config(): (eth0): option 'pid'=>'13782' Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Oct 18 18:35:00 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643641] [nm-system.c:182] sync_addresses(): (eth0): syncing addresses (family 10) Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643655] [nm-system.c:235] sync_addresses(): (eth0): removing address '2001:840:3033:20:230:1bff:febc:7f23/64' Oct 18 18:35:00 wrath NetworkManager[12390]: <debug> [1318955700.643702] [nm-system.c:218] sync_addresses(): (eth0): ignoring IPv6 link-local address Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS. Oct 18 18:35:01 wrath NetworkManager[12390]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656335] [nm-ip6-manager.c:1041] netlink_notification(): netlink notificate type 21 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656345] [nm-ip6-manager.c:542] process_addr(): processing netlink new/del address message Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656359] [nm-ip6-manager.c:1069] netlink_notification(): (eth0): syncing device with netlink changes Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656367] [nm-ip6-manager.c:419] nm_ip6_device_sync_from_netlink(): (eth0): syncing with netlink (ra_flags 0x800000B0) (state/target 'got-address'/'got-address') Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656376] [nm-ip6-manager.c:438] nm_ip6_device_sync_from_netlink(): (eth0): netlink address: fe80::230:1bff:febc:7f23 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656382] [nm-ip6-manager.c:460] nm_ip6_device_sync_from_netlink(): (eth0): addresses synced (state got-address) Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656388] [nm-ip6-manager.c:474] nm_ip6_device_sync_from_netlink(): router advertisement requests parallel DHCPv6 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656393] [nm-ip6-manager.c:512] nm_ip6_device_sync_from_netlink(): (eth0): RA-provided address no longer valid Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): DHCPv6 client pid 13782 exited with status 0 Oct 18 18:35:01 wrath NetworkManager[12390]: <debug> [1318955701.656448] [nm-device.c:1582] dhcp6_state_changed(): (eth0): new DHCPv6 client state 23 Oct 18 18:35:01 wrath NetworkManager[12390]: <info> (eth0): device state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5]
2011-10-21 14:25:35 -05:00
} else {
device/logging: downgrade log level of "Activation: Stage x of 5" messages Only downgrade the <info> levels to <debug>. Leave warnings unchanged. https://bugzilla.redhat.com/show_bug.cgi?id=1212196
2015-04-17 15:56:04 +02:00
_LOGW (LOGD_DEVICE | LOGD_IP6, "Activation: Stage 5 of 5 (IPv6 Commit) failed");
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
nm_device_ip_method_failed (self, AF_INET6, NM_DEVICE_STATE_REASON_CONFIG_FAILED);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
void
device: clean up ip6 configuration flow IP6 configuration is now stored in ac_ip6_config and dhcp6_ip6_config and passing them as function arguments is avoided. Written with Dan Williams.
2013-06-14 21:42:22 +02:00
nm_device_activate_schedule_ip6_config_result (NMDevice *self)
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
{
core: only log about IPv6 Commit the first time Since IPv6 configuration gets updated every time a router advertisement comes in, it can lead NM to continuously logging: NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. that's annoying. So after the initial configuration is done, make subsequent IPv6 Commit log messages debug instead of info.
2014-01-23 13:02:16 -06:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
g_return_if_fail (NM_IS_DEVICE (self));
rdisc: add RA wait timeout Add an advisory timeout when waiting for router advertisements so we can fail IPv6 addressing attempts when no router advertisement has been received.
2014-08-13 09:40:08 -05:00
/* If IP had previously failed, move it back to IP_CONF since we
* clearly now have configuration.
*/
if (priv->ip6_state == IP_FAIL)
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_CONF);
rdisc: add RA wait timeout Add an advisory timeout when waiting for router advertisements so we can fail IPv6 addressing attempts when no router advertisement has been received.
2014-08-13 09:40:08 -05:00
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
activation_source_schedule (self, activate_stage5_ip6_config_commit, AF_INET6);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
}
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
gboolean
nm_device_activate_ip6_state_in_conf (NMDevice *self)
{
g_return_val_if_fail (self != NULL, FALSE);
return NM_DEVICE_GET_PRIVATE (self)->ip6_state == IP_CONF;
}
core: expose IP4 wait state to subclasses We'll need to this to determine whether or not to retry IP config from device subclasses.
2013-01-28 13:34:44 -06:00
gboolean
nm_device_activate_ip6_state_in_wait (NMDevice *self)
{
g_return_val_if_fail (self != NULL, FALSE);
return NM_DEVICE_GET_PRIVATE (self)->ip6_state == IP_WAIT;
}
device: fail activation immediately only when may-fail=no Introduce the nm_device_ip_method_failed() function to check if the failure of an IP method should cause the activation to fail, and use it where appropriate. http://bugzilla.gnome.org/show_bug.cgi?id=741347
2016-04-07 13:48:34 +02:00
gboolean
nm_device_activate_ip6_state_done (NMDevice *self)
{
g_return_val_if_fail (self != NULL, FALSE);
return NM_DEVICE_GET_PRIVATE (self)->ip6_state == IP_DONE;
}
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
/*****************************************************************************/
2007-09-11 Dan Williams <dcbw@redhat.com> * libnm-util/nm-setting.c libnm-util/nm-setting.h - (nm_setting_update_secrets): new function; add a virtual function that subclasses can implement to update their secrets - (setting_wireless_security_update_secrets): implement that function for the 802-11-wireless-security subclass * libnm-util/nm-connection.c libnm-util/nm-connection.h - (nm_connection_update_secrets): update secrets for a Setting and emit a signal on success * src/nm-manager.c src/nm-manager.h src/nm-marshal.list - (connection_get_settings_cb): enable system settings bits - (nm_manager_get_connection_secrets, get_secrets_cb): add function to request secrets from the settings dbus service and to push those secrets to the NMConnection itself * src/nm-activation-request.c src/nm-activation-request.h - Attach to the 'secrets-updated' signal of the NMConnection that's currently being activated, and proxy that signal to other listeners. Goes through the activation request because the activation request is the thing that manages the lifetime of the NMConnection that's being activated. * src/nm-device-802-11-wireless.c - (real_connection_secrets_updated): implement the connection secrets updated notification and restart activation when secrets are received - (real_act_stage2_config): request secrets from the settings dbus service if secrets are needed * src/nm-device.c src/nm-device.h - (clear_act_request, nm_device_activation_cancel, nm_device_deactivate_quickly, nm_device_dispose): consolidate places where the activation request is cleared - (nm_device_activate, connection_secrets_updated_cb): attach to the updated secrets signal of activation request and add a function that subclasses can override to handle it easily git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2782 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-11 18:02:27 +00:00
static void
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
act_request_set_cb (NMActRequest *act_request,
GParamSpec *pspec,
NMDevice *self)
2007-09-11 Dan Williams <dcbw@redhat.com> * libnm-util/nm-setting.c libnm-util/nm-setting.h - (nm_setting_update_secrets): new function; add a virtual function that subclasses can implement to update their secrets - (setting_wireless_security_update_secrets): implement that function for the 802-11-wireless-security subclass * libnm-util/nm-connection.c libnm-util/nm-connection.h - (nm_connection_update_secrets): update secrets for a Setting and emit a signal on success * src/nm-manager.c src/nm-manager.h src/nm-marshal.list - (connection_get_settings_cb): enable system settings bits - (nm_manager_get_connection_secrets, get_secrets_cb): add function to request secrets from the settings dbus service and to push those secrets to the NMConnection itself * src/nm-activation-request.c src/nm-activation-request.h - Attach to the 'secrets-updated' signal of the NMConnection that's currently being activated, and proxy that signal to other listeners. Goes through the activation request because the activation request is the thing that manages the lifetime of the NMConnection that's being activated. * src/nm-device-802-11-wireless.c - (real_connection_secrets_updated): implement the connection secrets updated notification and restart activation when secrets are received - (real_act_stage2_config): request secrets from the settings dbus service if secrets are needed * src/nm-device.c src/nm-device.h - (clear_act_request, nm_device_activation_cancel, nm_device_deactivate_quickly, nm_device_dispose): consolidate places where the activation request is cleared - (nm_device_activate, connection_secrets_updated_cb): attach to the updated secrets signal of activation request and add a function that subclasses can override to handle it easily git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2782 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-11 18:02:27 +00:00
{
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
_notify (self, PROP_ACTIVE_CONNECTION);
}
2007-09-11 Dan Williams <dcbw@redhat.com> * libnm-util/nm-setting.c libnm-util/nm-setting.h - (nm_setting_update_secrets): new function; add a virtual function that subclasses can implement to update their secrets - (setting_wireless_security_update_secrets): implement that function for the 802-11-wireless-security subclass * libnm-util/nm-connection.c libnm-util/nm-connection.h - (nm_connection_update_secrets): update secrets for a Setting and emit a signal on success * src/nm-manager.c src/nm-manager.h src/nm-marshal.list - (connection_get_settings_cb): enable system settings bits - (nm_manager_get_connection_secrets, get_secrets_cb): add function to request secrets from the settings dbus service and to push those secrets to the NMConnection itself * src/nm-activation-request.c src/nm-activation-request.h - Attach to the 'secrets-updated' signal of the NMConnection that's currently being activated, and proxy that signal to other listeners. Goes through the activation request because the activation request is the thing that manages the lifetime of the NMConnection that's being activated. * src/nm-device-802-11-wireless.c - (real_connection_secrets_updated): implement the connection secrets updated notification and restart activation when secrets are received - (real_act_stage2_config): request secrets from the settings dbus service if secrets are needed * src/nm-device.c src/nm-device.h - (clear_act_request, nm_device_activation_cancel, nm_device_deactivate_quickly, nm_device_dispose): consolidate places where the activation request is cleared - (nm_device_activate, connection_secrets_updated_cb): attach to the updated secrets signal of activation request and add a function that subclasses can override to handle it easily git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2782 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-11 18:02:27 +00:00
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
static void
act_request_set (NMDevice *self, NMActRequest *act_request)
{
NMDevicePrivate *priv;
gs_unref_object NMActRequest *old_act_requst = NULL;
nm_assert (NM_IS_DEVICE (self));
nm_assert (!act_request || NM_IS_ACT_REQUEST (act_request));
priv = NM_DEVICE_GET_PRIVATE (self);
if ( !priv->act_request_public
&& priv->act_request == act_request)
2007-09-11 Dan Williams <dcbw@redhat.com> * libnm-util/nm-setting.c libnm-util/nm-setting.h - (nm_setting_update_secrets): new function; add a virtual function that subclasses can implement to update their secrets - (setting_wireless_security_update_secrets): implement that function for the 802-11-wireless-security subclass * libnm-util/nm-connection.c libnm-util/nm-connection.h - (nm_connection_update_secrets): update secrets for a Setting and emit a signal on success * src/nm-manager.c src/nm-manager.h src/nm-marshal.list - (connection_get_settings_cb): enable system settings bits - (nm_manager_get_connection_secrets, get_secrets_cb): add function to request secrets from the settings dbus service and to push those secrets to the NMConnection itself * src/nm-activation-request.c src/nm-activation-request.h - Attach to the 'secrets-updated' signal of the NMConnection that's currently being activated, and proxy that signal to other listeners. Goes through the activation request because the activation request is the thing that manages the lifetime of the NMConnection that's being activated. * src/nm-device-802-11-wireless.c - (real_connection_secrets_updated): implement the connection secrets updated notification and restart activation when secrets are received - (real_act_stage2_config): request secrets from the settings dbus service if secrets are needed * src/nm-device.c src/nm-device.h - (clear_act_request, nm_device_activation_cancel, nm_device_deactivate_quickly, nm_device_dispose): consolidate places where the activation request is cleared - (nm_device_activate, connection_secrets_updated_cb): attach to the updated secrets signal of activation request and add a function that subclasses can override to handle it easily git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2782 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-11 18:02:27 +00:00
return;
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
/* always clear the public flag. The few callers that set a new @act_request
* don't want that the property is public yet. */
priv->act_request_public = FALSE;
nm_clear_g_signal_handler (priv->act_request, &priv->act_request_id);
2008-06-09 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (clear_act_request): unset the 'default' property of the activation request when clearing it to ensure the property changed signal gets delivered and handled git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3735 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-06-10 02:01:13 +00:00
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
old_act_requst = priv->act_request;
priv->act_request = nm_g_object_ref (act_request);
core: add slave to master in stage1_prepare, not nm_device_activate() When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
2013-09-11 09:21:17 -05:00
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
if (act_request) {
priv->act_request_id = g_signal_connect (act_request,
"notify::"NM_EXPORTED_OBJECT_PATH,
G_CALLBACK (act_request_set_cb),
self);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
switch (nm_active_connection_get_activation_type (NM_ACTIVE_CONNECTION (act_request))) {
case NM_ACTIVATION_TYPE_EXTERNAL:
break;
case NM_ACTIVATION_TYPE_ASSUME:
if (priv->sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_EXTERNAL)
nm_device_sys_iface_state_set (self, NM_DEVICE_SYS_IFACE_STATE_ASSUME);
break;
case NM_ACTIVATION_TYPE_MANAGED:
if (NM_IN_SET_TYPED (NMDeviceSysIfaceState,
priv->sys_iface_state,
NM_DEVICE_SYS_IFACE_STATE_EXTERNAL,
NM_DEVICE_SYS_IFACE_STATE_ASSUME))
nm_device_sys_iface_state_set (self, NM_DEVICE_SYS_IFACE_STATE_MANAGED);
break;
}
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
}
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_ACTIVE_CONNECTION);
2007-09-11 Dan Williams <dcbw@redhat.com> * libnm-util/nm-setting.c libnm-util/nm-setting.h - (nm_setting_update_secrets): new function; add a virtual function that subclasses can implement to update their secrets - (setting_wireless_security_update_secrets): implement that function for the 802-11-wireless-security subclass * libnm-util/nm-connection.c libnm-util/nm-connection.h - (nm_connection_update_secrets): update secrets for a Setting and emit a signal on success * src/nm-manager.c src/nm-manager.h src/nm-marshal.list - (connection_get_settings_cb): enable system settings bits - (nm_manager_get_connection_secrets, get_secrets_cb): add function to request secrets from the settings dbus service and to push those secrets to the NMConnection itself * src/nm-activation-request.c src/nm-activation-request.h - Attach to the 'secrets-updated' signal of the NMConnection that's currently being activated, and proxy that signal to other listeners. Goes through the activation request because the activation request is the thing that manages the lifetime of the NMConnection that's being activated. * src/nm-device-802-11-wireless.c - (real_connection_secrets_updated): implement the connection secrets updated notification and restart activation when secrets are received - (real_act_stage2_config): request secrets from the settings dbus service if secrets are needed * src/nm-device.c src/nm-device.h - (clear_act_request, nm_device_activation_cancel, nm_device_deactivate_quickly, nm_device_dispose): consolidate places where the activation request is cleared - (nm_device_activate, connection_secrets_updated_cb): attach to the updated secrets signal of activation request and add a function that subclasses can override to handle it easily git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2782 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-11 18:02:27 +00:00
}
core: simplify DHCP setup and cleanup nm_device_set_use_dhcp() and nm_device_get_use_dhcp() were somewhat confusing and don't really reflect the new DHCP architecture with NMDHCPClient. Now that timeout and state signals are specific to the NMDHCPClient it doesn't make sense to check for DHCP use in the callbacks for those signals since they'll never get called if DHCP isn't in use. We might as well just keep the DHCP manager around and check whether a DHCP client instance exists when we need to figure out whether DHCP is in use.
2010-01-13 17:59:54 -08:00
static void
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
dnsmasq_cleanup (NMDevice *self)
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if (!priv->dnsmasq_manager)
return;
core: use nm_clear_g_signal_handler() where possible Replacement was done with command: spatch --sp-file nm_clear_g_signal_handler.cocci --in-place --smpl-spacing --dir src where nm_clear_g_signal_handler.cocci contains: @@ expression obj, id; @@ - if (id) { - g_signal_handler_disconnect (obj, id); - id = 0; - } + nm_clear_g_signal_handler (obj, &id);
2016-01-04 10:35:11 +01:00
nm_clear_g_signal_handler (priv->dnsmasq_manager, &priv->dnsmasq_state_id);
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
nm_dnsmasq_manager_stop (priv->dnsmasq_manager);
g_object_unref (priv->dnsmasq_manager);
priv->dnsmasq_manager = NULL;
}
core: move NMDevice private functions to nm-device-private.h Move stuff that's not "public" API of NMDevice to the private header that's only used by subclasses.
2011-11-17 22:39:34 -06:00
static void
_update_ip4_address (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
const NMPlatformIP4Address *address;
core: move NMDevice private functions to nm-device-private.h Move stuff that's not "public" API of NMDevice to the private header that's only used by subclasses.
2011-11-17 22:39:34 -06:00
device: don't call ioctl to update priv->ip4_address Just take the first address in priv->ip4_config.
2015-08-07 09:33:46 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
core: move NMDevice private functions to nm-device-private.h Move stuff that's not "public" API of NMDevice to the private header that's only used by subclasses.
2011-11-17 22:39:34 -06:00
device: avoid a crash during destruction The ipv4_config might be gone already, _cleanup_generic_post() sets it to NULL. NetworkManager[30564]: <info> caught SIGINT, shutting down normally. (NetworkManager:30564): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion 'instance != NULL && instance->g_class != NULL' failed Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x7ffff4d92f64 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd5e0) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff4a738c3 in g_logv (log_domain=0x7ffff4d92f64 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd5e0) at gmessages.c:1046 #1 0x00007ffff4a73a3f in g_log (log_domain=log_domain@entry=0x7ffff4d92f64 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff4ae173d "%s: assertion '%s' failed") at gmessages.c:1079 #2 0x00007ffff4a73a79 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff4d92f64 "GLib-GObject", pretty_function=pretty_function@entry=0x7ffff4d9aad0 <__FUNCTION__.13620> "g_type_instance_get_private", expression=expression@entry=0x7ffff4d99db8 "instance != NULL && instance->g_class != NULL") at gmessages.c:1088 #3 0x00007ffff4d8d2ba in g_type_instance_get_private (instance=instance@entry=0x0, private_type=<optimized out>) at gtype.c:4632 #4 0x00000000004bf774 in nm_ip4_config_get_num_addresses (config=0x0) at nm-ip4-config.c:1418 #5 0x0000000000458834 in _update_ip4_address (self=self@entry=0xa8a490 [NMDeviceBridge]) at devices/nm-device.c:6069 #6 0x000000000045e740 in nm_device_set_ip4_config (self=self@entry=0xa8a490 [NMDeviceBridge], new_config=new_config@entry=0x0, default_route_metric=default_route_metric@entry=0, commit=commit@entry=1, routes_full_sync=routes_full_sync@entry=1, reason=reason@entry=0x7fffffffd7cc) at devices/nm-device.c:6558 #7 0x0000000000466c56 in _cleanup_generic_post (self=self@entry=0xa8a490 [NMDeviceBridge], cleanup_type=cleanup_type@entry=CLEANUP_TYPE_KEEP) at devices/nm-device.c:8108 #8 0x00000000004671af in dispose (object=0xa8a490 [NMDeviceBridge]) at devices/nm-device.c:9128 #9 0x00007ffff4d6ea82 in g_object_unref (_object=0xa8a490) at gobject.c:3133 #10 0x00000000004d1a53 in remove_device (manager=manager@entry=0x8822b0 [NMManager], device=0xa8a490 [NMDeviceBridge], quitting=quitting@entry=1, allow_unmanage=allow_unmanage@entry=1) at nm-manager.c:780 #11 0x00000000004d7db1 in nm_manager_stop (self=self@entry=0x8822b0 [NMManager]) at nm-manager.c:4199 #12 0x0000000000445aa9 in main (argc=1, argv=0x7fffffffda88) at main.c:465 (gdb)
2015-08-12 16:03:12 +02:00
if ( priv->ip4_config
&& ip_config_valid (priv->state)
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
&& (address = nm_ip4_config_get_first_address (priv->ip4_config))) {
if (address->address != priv->ip4_address) {
priv->ip4_address = address->address;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IP4_ADDRESS);
device: don't call ioctl to update priv->ip4_address Just take the first address in priv->ip4_config.
2015-08-07 09:33:46 +02:00
}
core: move NMDevice private functions to nm-device-private.h Move stuff that's not "public" API of NMDevice to the private header that's only used by subclasses.
2011-11-17 22:39:34 -06:00
}
}
core: rearrange and remove some NMDevice getters For any function in nm-device.h which is not used outside of nm-device.c, remove the public prototypes. Functions that are actually used get moved above their caller, and functions that have no callers are removed.
2014-05-20 16:39:57 -05:00
gboolean
device: rename priv->is_nm_owned to priv->nm_owned Only a matter of taste, but nm_device_get_is_nm_owned() sounds strange.
2017-05-31 16:42:05 +02:00
nm_device_is_nm_owned (NMDevice *self)
core: rearrange and remove some NMDevice getters For any function in nm-device.h which is not used outside of nm-device.c, remove the public prototypes. Functions that are actually used get moved above their caller, and functions that have no callers are removed.
2014-05-20 16:39:57 -05:00
{
device: rename priv->is_nm_owned to priv->nm_owned Only a matter of taste, but nm_device_get_is_nm_owned() sounds strange.
2017-05-31 16:42:05 +02:00
return NM_DEVICE_GET_PRIVATE (self)->nm_owned;
core: rearrange and remove some NMDevice getters For any function in nm-device.h which is not used outside of nm-device.c, remove the public prototypes. Functions that are actually used get moved above their caller, and functions that have no callers are removed.
2014-05-20 16:39:57 -05:00
}
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
/*
* delete_on_deactivate_link_delete
*
* Function will be queued with g_idle_add to call
* nm_platform_link_delete for the underlying resources
* of the device.
*/
static gboolean
delete_on_deactivate_link_delete (gpointer user_data)
{
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
DeleteOnDeactivateData *data = user_data;
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
NMDevice *self = data->device;
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
_LOGD (LOGD_DEVICE, "delete_on_deactivate: cleanup and delete virtual link #%d (id=%u)",
data->ifindex, data->idle_add_id);
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
if (data->device) {
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (data->device);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
gs_free_error GError *error = NULL;
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
g_object_remove_weak_pointer (G_OBJECT (data->device), (void **) &data->device);
priv->delete_on_deactivate_data = NULL;
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
if (!nm_device_unrealize (data->device, TRUE, &error))
_LOGD (LOGD_DEVICE, "delete_on_deactivate: unrealizing %d failed (%s)", data->ifindex, error->message);
device: do not limit unrealizement to devices with platform links
2017-10-11 20:14:51 +02:00
} else if (data->ifindex > 0)
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_delete (nm_device_get_platform (self), data->ifindex);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
g_free (data);
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
return FALSE;
}
static void
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
delete_on_deactivate_unschedule (NMDevice *self)
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
{
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->delete_on_deactivate_data) {
DeleteOnDeactivateData *data = priv->delete_on_deactivate_data;
priv->delete_on_deactivate_data = NULL;
g_source_remove (data->idle_add_id);
g_object_remove_weak_pointer (G_OBJECT (self), (void **) &data->device);
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "delete_on_deactivate: cancel cleanup and delete virtual link #%d (id=%u)",
data->ifindex, data->idle_add_id);
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
g_free (data);
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
}
}
static void
delete_on_deactivate_check_and_schedule (NMDevice *self, int ifindex)
{
core: rearrange and remove some NMDevice getters For any function in nm-device.h which is not used outside of nm-device.c, remove the public prototypes. Functions that are actually used get moved above their caller, and functions that have no callers are removed.
2014-05-20 16:39:57 -05:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
DeleteOnDeactivateData *data;
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
device: rename priv->is_nm_owned to priv->nm_owned Only a matter of taste, but nm_device_get_is_nm_owned() sounds strange.
2017-05-31 16:42:05 +02:00
if (!priv->nm_owned)
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
return;
device: Don't delete the link if a re-activation is scheduled
2014-11-04 09:41:42 +01:00
if (priv->queued_act_request)
return;
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
if (!nm_device_is_software (self) || !nm_device_is_real (self))
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
return;
if (nm_device_get_state (self) == NM_DEVICE_STATE_UNMANAGED)
return;
device: do not remove software devices on initial disconnected (rh #1035814) When a device is initialized to be managed, it will transition through states unmanaged -> unavailable -> disconnected. We don't want to remove software devices during this initial transition to disconnected, because it prevents auto-activation. Test case: $ nmcli con add type vlan ifname myvlan dev eth0 id 123 NM should immediately create myvlan interface and automatically activate it. https://bugzilla.redhat.com/show_bug.cgi?id=1035814
2013-12-03 09:37:58 +01:00
if (nm_device_get_state (self) == NM_DEVICE_STATE_UNAVAILABLE)
return;
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
delete_on_deactivate_unschedule (self); /* always cancel and reschedule */
data = g_new (DeleteOnDeactivateData, 1);
g_object_add_weak_pointer (G_OBJECT (self), (void **) &data->device);
data->device = self;
data->ifindex = ifindex;
data->idle_add_id = g_idle_add (delete_on_deactivate_link_delete, data);
priv->delete_on_deactivate_data = data;
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "delete_on_deactivate: schedule cleanup and delete virtual link #%d (id=%u)",
ifindex, data->idle_add_id);
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
}
device: refactor the ip cleanup Split it up and move upwards. It will be useful for runtime reconfig of IPv4 configuration.
2015-11-21 12:28:09 +01:00
static void
_cleanup_ip4_pre (NMDevice *self, CleanupType cleanup_type)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_NONE);
device: refactor clearing @queued_ip4_config_id and @queued_ip6_config_id
2016-05-05 10:58:10 +02:00
if (nm_clear_g_source (&priv->queued_ip4_config_id))
_LOGD (LOGD_DEVICE, "clearing queued IP4 config change");
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
priv->queued_ip4_config_pending = FALSE;
device: refactor the ip cleanup Split it up and move upwards. It will be useful for runtime reconfig of IPv4 configuration.
2015-11-21 12:28:09 +01:00
dhcp4_cleanup (self, cleanup_type, FALSE);
arp_cleanup (self);
dnsmasq_cleanup (self);
ipv4ll_cleanup (self);
}
static void
_cleanup_ip6_pre (NMDevice *self, CleanupType cleanup_type)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_NONE);
device: refactor clearing @queued_ip4_config_id and @queued_ip6_config_id
2016-05-05 10:58:10 +02:00
if (nm_clear_g_source (&priv->queued_ip6_config_id))
_LOGD (LOGD_DEVICE, "clearing queued IP6 config change");
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
priv->queued_ip6_config_pending = FALSE;
device: refactor the ip cleanup Split it up and move upwards. It will be useful for runtime reconfig of IPv4 configuration.
2015-11-21 12:28:09 +01:00
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
g_clear_object (&priv->dad6_ip6_config);
device: refactor the ip cleanup Split it up and move upwards. It will be useful for runtime reconfig of IPv4 configuration.
2015-11-21 12:28:09 +01:00
dhcp6_cleanup (self, cleanup_type, FALSE);
linklocal6_cleanup (self);
addrconf6_cleanup (self);
}
device: internally export nm_device_hash_check_invalid_keys()
2017-03-03 12:03:26 +01:00
gboolean
_nm_device_hash_check_invalid_keys (GHashTable *hash, const char *setting_name,
GError **error, const char **argv)
device: add possibility to reapply the ipv4 settings
2016-01-05 15:52:36 +01:00
{
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
guint found_keys = 0;
device: don't iterate over a va_list more then once Calling va_start() (with va_end()) in between seems to work and is done by systemd and other code occasionally. However, it's not clear that this really works on every architecture. So just replace thise one instance with a different implementation by passing the arguments as an array.
2016-01-29 14:07:16 +01:00
guint i;
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
nm_assert (hash && g_hash_table_size (hash) > 0);
device: don't iterate over a va_list more then once Calling va_start() (with va_end()) in between seems to work and is done by systemd and other code occasionally. However, it's not clear that this really works on every architecture. So just replace thise one instance with a different implementation by passing the arguments as an array.
2016-01-29 14:07:16 +01:00
nm_assert (argv && argv[0]);
device: add possibility to reapply the ipv4 settings
2016-01-05 15:52:36 +01:00
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
#if NM_MORE_ASSERTS > 10
/* Assert that the keys are unique. */
{
core,clients: use our own string hashing function nm_str_hash() Replace the usage of g_str_hash() with our own nm_str_hash(). GLib's g_str_hash() uses djb2 hashing function, just like we do at the moment. The only difference is, that we use a diffrent seed value. Note, that we initialize the hash seed with random data (by calling getrandom() or reading /dev/urandom). That is a change compared to before. This change of the hashing function and accessing the random pool might be undesired for libnm/libnm-core. Hence, the change is not done there as it possibly changes behavior for public API. Maybe we should do that later though. At this point, there isn't much of a change. This patch becomes interesting, if we decide to use a different hashing algorithm.
2017-10-13 16:12:35 +02:00
gs_unref_hashtable GHashTable *check_dups = g_hash_table_new_full (nm_str_hash, g_str_equal, NULL, NULL);
device: add possibility to reapply the ipv4 settings
2016-01-05 15:52:36 +01:00
device: don't iterate over a va_list more then once Calling va_start() (with va_end()) in between seems to work and is done by systemd and other code occasionally. However, it's not clear that this really works on every architecture. So just replace thise one instance with a different implementation by passing the arguments as an array.
2016-01-29 14:07:16 +01:00
for (i = 0; argv[i]; i++) {
device: fix build with old glib & more asserts src/devices/nm-device.c:8319:4: error: invalid use of void expression (cherry picked from commit a4d61bf29905ac9e5c7e6f99344733a4ccb2297f)
2017-01-18 13:24:42 +01:00
if (!nm_g_hash_table_add (check_dups, (char *) argv[i]))
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
nm_assert (FALSE);
device: add possibility to reapply the ipv4 settings
2016-01-05 15:52:36 +01:00
}
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
nm_assert (g_hash_table_size (check_dups) > 0);
device: add possibility to reapply the ipv4 settings
2016-01-05 15:52:36 +01:00
}
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
#endif
device: add possibility to reapply the ipv4 settings
2016-01-05 15:52:36 +01:00
device: don't iterate over a va_list more then once Calling va_start() (with va_end()) in between seems to work and is done by systemd and other code occasionally. However, it's not clear that this really works on every architecture. So just replace thise one instance with a different implementation by passing the arguments as an array.
2016-01-29 14:07:16 +01:00
for (i = 0; argv[i]; i++) {
if (g_hash_table_contains (hash, argv[i]))
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
found_keys++;
device: add possibility to reapply the ipv6 settings
2016-01-05 15:54:00 +01:00
}
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
if (found_keys != g_hash_table_size (hash)) {
GHashTableIter iter;
const char *k = NULL;
const char *first_invalid_key = NULL;
device: add possibility to reapply the ipv6 settings
2016-01-05 15:54:00 +01:00
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
if (!error)
return FALSE;
device: apply the firewall zone and metered state on Reapply() Reuse some code with the immediate reapply mechanism.
2016-01-05 15:54:44 +01:00
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_hash_table_iter_init (&iter, hash);
while (g_hash_table_iter_next (&iter, (gpointer *) &k, NULL)) {
all: use nm_utils_strv_find_first() from shared/nm-utils
2017-02-04 17:53:17 +01:00
if (nm_utils_strv_find_first ((char **) argv, -1, k) < 0) {
device: fix check for invalid keys during reapply Was completely wrong and failed to find first_invalid_key. As a consequence, hit the assertion at the end.
2016-04-30 12:49:43 +02:00
first_invalid_key = k;
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
break;
device: fix check for invalid keys during reapply Was completely wrong and failed to find first_invalid_key. As a consequence, hit the assertion at the end.
2016-04-30 12:49:43 +02:00
}
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
}
device: improve error message for failure to reapply
2016-04-30 12:56:25 +02:00
if (setting_name) {
g_set_error (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION,
"Can't reapply changes to '%s.%s' setting",
setting_name,
first_invalid_key);
} else {
g_set_error (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION,
"Can't reapply any changes to '%s' setting",
first_invalid_key);
}
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_return_val_if_fail (first_invalid_key, FALSE);
device: apply the firewall zone and metered state on Reapply() Reuse some code with the immediate reapply mechanism.
2016-01-05 15:54:44 +01:00
return FALSE;
}
return TRUE;
}
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
void
nm_device_reactivate_ip4_config (NMDevice *self,
NMSettingIPConfig *s_ip4_old,
device: force restart of IP method during reapply Scenario: Have a connection with DHCPv4 and a default-route. When externally removing the default route (`ip route delete 0.0.0.0/0`) and issuing `nmcli device reapply $IF`, the default route was not restored. That was because when externally removing the default route, we would remove the gateway from priv->con_ip4_config (see update_ip4_config()). Later, when reapplying the connection, the IP method doesn't actually change. So we would not restart DHCP and thus there is no gateway around to add the default route. The default route would only be restored after receiving a DHCP lease in the far future. Fix that, by always restarting the IP method.
2017-03-16 14:54:16 +01:00
NMSettingIPConfig *s_ip4_new,
gboolean force_restart)
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
{
NMDevicePrivate *priv;
device: fix crash reapplying connection to slave devices Slave devices don't have IPv4 and IPv6 configuration and so special care must be taken when comparing their methods. https://bugzilla.redhat.com/show_bug.cgi?id=1376446
2016-09-16 05:12:45 +02:00
const char *method_old, *method_new;
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->ip4_state != IP_NONE) {
g_clear_object (&priv->con_ip4_config);
device: drop external changes on Reapply https://bugzilla.gnome.org/show_bug.cgi?id=762322
2016-03-29 13:50:39 +02:00
g_clear_object (&priv->ext_ip4_config);
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
priv->con_ip4_config = _ip4_config_new (self);
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
nm_ip4_config_merge_setting (priv->con_ip4_config,
s_ip4_new,
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
nm_device_get_route_table (self, AF_INET, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET));
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
device: force restart of IP method during reapply Scenario: Have a connection with DHCPv4 and a default-route. When externally removing the default route (`ip route delete 0.0.0.0/0`) and issuing `nmcli device reapply $IF`, the default route was not restored. That was because when externally removing the default route, we would remove the gateway from priv->con_ip4_config (see update_ip4_config()). Later, when reapplying the connection, the IP method doesn't actually change. So we would not restart DHCP and thus there is no gateway around to add the default route. The default route would only be restored after receiving a DHCP lease in the far future. Fix that, by always restarting the IP method.
2017-03-16 14:54:16 +01:00
if (!force_restart) {
method_old = s_ip4_old
? nm_setting_ip_config_get_method (s_ip4_old)
: NM_SETTING_IP4_CONFIG_METHOD_DISABLED;
method_new = s_ip4_new
? nm_setting_ip_config_get_method (s_ip4_new)
: NM_SETTING_IP4_CONFIG_METHOD_DISABLED;
force_restart = !nm_streq0 (method_old, method_new);
}
device: fix crash reapplying connection to slave devices Slave devices don't have IPv4 and IPv6 configuration and so special care must be taken when comparing their methods. https://bugzilla.redhat.com/show_bug.cgi?id=1376446
2016-09-16 05:12:45 +02:00
device: force restart of IP method during reapply Scenario: Have a connection with DHCPv4 and a default-route. When externally removing the default route (`ip route delete 0.0.0.0/0`) and issuing `nmcli device reapply $IF`, the default route was not restored. That was because when externally removing the default route, we would remove the gateway from priv->con_ip4_config (see update_ip4_config()). Later, when reapplying the connection, the IP method doesn't actually change. So we would not restart DHCP and thus there is no gateway around to add the default route. The default route would only be restored after receiving a DHCP lease in the far future. Fix that, by always restarting the IP method.
2017-03-16 14:54:16 +01:00
if (force_restart) {
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
_cleanup_ip4_pre (self, CLEANUP_TYPE_DECONFIGURE);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET, IP_WAIT);
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
if (!nm_device_activate_stage3_ip4_start (self))
_LOGW (LOGD_IP4, "Failed to apply IPv4 configuration");
device: warn if we couldn't reapply the ip configuration Coverity is suspicious and rightly so.
2016-02-12 14:19:46 +01:00
} else {
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
if (!ip4_config_merge_and_apply (self, TRUE))
device: warn if we couldn't reapply the ip configuration Coverity is suspicious and rightly so.
2016-02-12 14:19:46 +01:00
_LOGW (LOGD_IP4, "Failed to reapply IPv4 configuration");
}
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
}
}
void
nm_device_reactivate_ip6_config (NMDevice *self,
NMSettingIPConfig *s_ip6_old,
device: force restart of IP method during reapply Scenario: Have a connection with DHCPv4 and a default-route. When externally removing the default route (`ip route delete 0.0.0.0/0`) and issuing `nmcli device reapply $IF`, the default route was not restored. That was because when externally removing the default route, we would remove the gateway from priv->con_ip4_config (see update_ip4_config()). Later, when reapplying the connection, the IP method doesn't actually change. So we would not restart DHCP and thus there is no gateway around to add the default route. The default route would only be restored after receiving a DHCP lease in the far future. Fix that, by always restarting the IP method.
2017-03-16 14:54:16 +01:00
NMSettingIPConfig *s_ip6_new,
gboolean force_restart)
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
{
NMDevicePrivate *priv;
device: fix crash reapplying connection to slave devices Slave devices don't have IPv4 and IPv6 configuration and so special care must be taken when comparing their methods. https://bugzilla.redhat.com/show_bug.cgi?id=1376446
2016-09-16 05:12:45 +02:00
const char *method_old, *method_new;
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->ip6_state != IP_NONE) {
g_clear_object (&priv->con_ip6_config);
device: drop external changes on Reapply https://bugzilla.gnome.org/show_bug.cgi?id=762322
2016-03-29 13:50:39 +02:00
g_clear_object (&priv->ext_ip6_config);
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
priv->con_ip6_config = _ip6_config_new (self);
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
nm_ip6_config_merge_setting (priv->con_ip6_config,
s_ip6_new,
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
nm_device_get_route_table (self, AF_INET6, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET6));
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
device: force restart of IP method during reapply Scenario: Have a connection with DHCPv4 and a default-route. When externally removing the default route (`ip route delete 0.0.0.0/0`) and issuing `nmcli device reapply $IF`, the default route was not restored. That was because when externally removing the default route, we would remove the gateway from priv->con_ip4_config (see update_ip4_config()). Later, when reapplying the connection, the IP method doesn't actually change. So we would not restart DHCP and thus there is no gateway around to add the default route. The default route would only be restored after receiving a DHCP lease in the far future. Fix that, by always restarting the IP method.
2017-03-16 14:54:16 +01:00
if (!force_restart) {
method_old = s_ip6_old
? nm_setting_ip_config_get_method (s_ip6_old)
: NM_SETTING_IP6_CONFIG_METHOD_IGNORE;
method_new = s_ip6_new
? nm_setting_ip_config_get_method (s_ip6_new)
: NM_SETTING_IP6_CONFIG_METHOD_IGNORE;
force_restart = !nm_streq0 (method_old, method_new);
}
device: fix crash reapplying connection to slave devices Slave devices don't have IPv4 and IPv6 configuration and so special care must be taken when comparing their methods. https://bugzilla.redhat.com/show_bug.cgi?id=1376446
2016-09-16 05:12:45 +02:00
device: force restart of IP method during reapply Scenario: Have a connection with DHCPv4 and a default-route. When externally removing the default route (`ip route delete 0.0.0.0/0`) and issuing `nmcli device reapply $IF`, the default route was not restored. That was because when externally removing the default route, we would remove the gateway from priv->con_ip4_config (see update_ip4_config()). Later, when reapplying the connection, the IP method doesn't actually change. So we would not restart DHCP and thus there is no gateway around to add the default route. The default route would only be restored after receiving a DHCP lease in the far future. Fix that, by always restarting the IP method.
2017-03-16 14:54:16 +01:00
if (force_restart) {
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
_cleanup_ip6_pre (self, CLEANUP_TYPE_DECONFIGURE);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_WAIT);
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
if (!nm_device_activate_stage3_ip6_start (self))
_LOGW (LOGD_IP6, "Failed to apply IPv6 configuration");
device: warn if we couldn't reapply the ip configuration Coverity is suspicious and rightly so.
2016-02-12 14:19:46 +01:00
} else {
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (!ip6_config_merge_and_apply (self, TRUE))
device: warn if we couldn't reapply the ip configuration Coverity is suspicious and rightly so.
2016-02-12 14:19:46 +01:00
_LOGW (LOGD_IP4, "Failed to reapply IPv6 configuration");
}
device: export nm_device_reactivate_ip{4,6}_config functions nm_device_reactivate_ip6_config() will be used to reconfigure IPv6 addressing when a VLAN interface changes MAC.
2016-01-11 09:59:25 +01:00
}
}
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
static void
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
_pacrunner_manager_send (NMDevice *self)
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
nm_pacrunner_manager_remove_clear (priv->pacrunner_manager,
&priv->pacrunner_call_id);
device: fix removal of pacrunner configurations Don't try to remove the configuration if we haven't added it in the first place, for example when the connection gets deactivated before it completes or for slave connections without IP configuration. Fixes: 3ad89223d0ea9a772b650842d15583d92cf9a904
2017-04-07 10:23:22 +02:00
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
if (!priv->pacrunner_manager)
priv->pacrunner_manager = g_object_ref (nm_pacrunner_manager_get ());
priv->pacrunner_call_id = nm_pacrunner_manager_send (priv->pacrunner_manager,
nm_device_get_ip_iface (self),
priv->proxy_config,
NULL,
NULL);
}
static void
reactivate_proxy_config (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
if (!priv->pacrunner_call_id)
return;
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
nm_device_set_proxy_config (self, priv->dhcp4.pac_url);
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
_pacrunner_manager_send (self);
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
}
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
static gboolean
can_reapply_change (NMDevice *self, const char *setting_name,
NMSetting *s_old, NMSetting *s_new,
GHashTable *diffs, GError **error)
{
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
if (nm_streq (setting_name, NM_SETTING_CONNECTION_SETTING_NAME)) {
/* Whitelist allowed properties from "connection" setting which are
* allowed to differ.
*
* This includes UUID, there is no principal problem with reapplying a
* connection and changing it's UUID. In fact, disallowing it makes it
* cumbersome for the user to reapply any connection but the original
* settings-connection. */
return nm_device_hash_check_invalid_keys (diffs,
NM_SETTING_CONNECTION_SETTING_NAME,
error,
NM_SETTING_CONNECTION_ID,
NM_SETTING_CONNECTION_UUID,
NM_SETTING_CONNECTION_STABLE_ID,
NM_SETTING_CONNECTION_AUTOCONNECT,
NM_SETTING_CONNECTION_ZONE,
NM_SETTING_CONNECTION_METERED,
NM_SETTING_CONNECTION_LLDP);
} else if (NM_IN_STRSET (setting_name,
NM_SETTING_IP4_CONFIG_SETTING_NAME,
NM_SETTING_IP6_CONFIG_SETTING_NAME,
NM_SETTING_PROXY_SETTING_NAME)) {
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
if (g_hash_table_contains (diffs, NM_SETTING_IP_CONFIG_ROUTE_TABLE)) {
/* changing the route-table setting is complicated, because it affects
* how we sync the routes. Don't support changing it without full
* re-activation.
*
* The problem is really that changing the setting also affects the sync
* mode. So, switching from NM_IP_ROUTE_TABLE_SYNC_MODE_MAIN to
* NM_IP_ROUTE_TABLE_SYNC_MODE_FULL would somehow require us to get rid
* of additional routes, but we don't know which routes were added by NM
* and which should be removed.
*
* Note how nm_device_get_route_table() caches the value for the duration of the
* activation. */
g_set_error (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION,
"Can't reapply changes to '%s.%s' setting",
setting_name,
NM_SETTING_IP_CONFIG_ROUTE_TABLE);
return FALSE;
}
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
return TRUE;
} else {
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
g_set_error (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION,
"Can't reapply any changes to '%s' setting",
setting_name);
return FALSE;
}
}
static void
reapply_connection (NMDevice *self, NMConnection *con_old, NMConnection *con_new)
{
}
/* check_and_reapply_connection:
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
* @connection: the new connection settings to be applied or %NULL to reapply
* the current settings connection
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
* @version_id: either zero, or the current version id for the applied
* connection.
device: add list of changed properties to reapply audit log
2017-03-04 00:21:22 +01:00
* @audit_args: on return, a string representing the changes
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
* @error: the error if %FALSE is returned
*
* Change configuration of an already configured device if possible.
* Updates the device's applied connection upon success.
*
* Return: %FALSE if the new configuration can not be reapplied.
*/
static gboolean
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
check_and_reapply_connection (NMDevice *self,
NMConnection *connection,
guint64 version_id,
device: add list of changed properties to reapply audit log
2017-03-04 00:21:22 +01:00
char **audit_args,
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
GError **error)
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
{
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
NMDeviceClass *klass = NM_DEVICE_GET_CLASS (self);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
NMConnection *applied = nm_device_get_applied_connection (self);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
gs_unref_object NMConnection *applied_clone = NULL;
gs_unref_hashtable GHashTable *diffs = NULL;
NMConnection *con_old, *con_new;
NMSettingIPConfig *s_ip4_old, *s_ip4_new;
NMSettingIPConfig *s_ip6_old, *s_ip6_new;
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
GHashTableIter iter;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
if (priv->state != NM_DEVICE_STATE_ACTIVATED) {
g_set_error_literal (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_NOT_ACTIVE,
"Device is not activated");
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
return FALSE;
}
nm_connection_diff (connection,
applied,
NM_SETTING_COMPARE_FLAG_IGNORE_TIMESTAMP |
NM_SETTING_COMPARE_FLAG_IGNORE_SECRETS,
&diffs);
device: fix taking over device after modifying external connection For externally managed interfaces, we create an in-memory connection and keep the device with sys-iface-state=external. When the user actively modifies the connection, we persist it to storage. But we also must take over managing the device. One problem is that nm_device_reapply() errors out if the device is still activating. It's unclear how to reapply the connection while the device is in the process of activation. So, if the user modifies the created connection very quickly, reapplying the settings will fail. https://bugzilla.redhat.com/show_bug.cgi?id=1462223
2017-06-16 13:06:26 +02:00
if (audit_args) {
if (diffs && nm_audit_manager_audit_enabled (nm_audit_manager_get ()))
*audit_args = nm_utils_format_con_diff_for_audit (diffs);
else
*audit_args = NULL;
}
device: add list of changed properties to reapply audit log
2017-03-04 00:21:22 +01:00
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
/**************************************************************************
* check for unsupported changes and reject to reapply
*************************************************************************/
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
if (diffs) {
char *setting_name;
GHashTable *setting_diff;
g_hash_table_iter_init (&iter, diffs);
while (g_hash_table_iter_next (&iter, (gpointer *) &setting_name, (gpointer *) &setting_diff)) {
if (!klass->can_reapply_change (self,
setting_name,
nm_connection_get_setting_by_name (applied, setting_name),
nm_connection_get_setting_by_name (connection, setting_name),
setting_diff,
error))
return FALSE;
}
}
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
if ( version_id != 0
&& version_id != nm_active_connection_version_id_get ((NMActiveConnection *) priv->act_request)) {
g_set_error_literal (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_VERSION_ID_MISMATCH,
"Reapply failed because device changed in the meantime and the version-id mismatches");
return FALSE;
}
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
/**************************************************************************
* Update applied connection
*************************************************************************/
core: add version-id to NMActiveConnection This field will be later used by NMDevice's Reapply and GetAppliedConnection methods. The usecase is to first fetch the currently applied connection, adjust it and reapply it. Using the version-id, a concurrent modification can be detected and Reapply can reject the invocation.
2016-02-11 08:36:39 +01:00
if (diffs)
nm_active_connection_version_id_bump ((NMActiveConnection *) priv->act_request);
_LOGD (LOGD_DEVICE, "reapply (version-id %llu%s)",
all: use "unsigned long" instead of "long unsigned"
2017-03-14 11:15:05 +01:00
(unsigned long long) nm_active_connection_version_id_get (((NMActiveConnection *) priv->act_request)),
core: add version-id to NMActiveConnection This field will be later used by NMDevice's Reapply and GetAppliedConnection methods. The usecase is to first fetch the currently applied connection, adjust it and reapply it. Using the version-id, a concurrent modification can be detected and Reapply can reject the invocation.
2016-02-11 08:36:39 +01:00
diffs ? "" : " (unmodified)");
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
if (diffs) {
device: avoid changing immutable properties during reapply We allow to reapply a connection with different id, uuid, stable-id, autoconnect value. This is allowed for convenience, so that a user can reapply a connection that differs in these fields. But actually, these fields cannot be reapplied. That is, their new values are not considered and the old values are continued to be used. Thus, mangle the reapplied connection to use the original, actually used values.
2017-01-10 20:07:23 +01:00
NMConnection *connection_clean = connection;
gs_free NMConnection *connection_clean_free = NULL;
{
NMSettingConnection *s_con_a, *s_con_n;
/* we allow re-applying a connection with differing ID, UUID, STABLE_ID and AUTOCONNECT.
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
* This is for convenience but these values are not actually changeable. So, check
device: avoid changing immutable properties during reapply We allow to reapply a connection with different id, uuid, stable-id, autoconnect value. This is allowed for convenience, so that a user can reapply a connection that differs in these fields. But actually, these fields cannot be reapplied. That is, their new values are not considered and the old values are continued to be used. Thus, mangle the reapplied connection to use the original, actually used values.
2017-01-10 20:07:23 +01:00
* if they changed, and if the did revert to the original values. */
s_con_a = nm_connection_get_setting_connection (applied);
s_con_n = nm_connection_get_setting_connection (connection);
if ( !nm_streq (nm_setting_connection_get_id (s_con_a), nm_setting_connection_get_id (s_con_n))
|| !nm_streq (nm_setting_connection_get_uuid (s_con_a), nm_setting_connection_get_uuid (s_con_n))
|| nm_setting_connection_get_autoconnect (s_con_a) != nm_setting_connection_get_autoconnect (s_con_n)
|| !nm_streq0 (nm_setting_connection_get_stable_id (s_con_a), nm_setting_connection_get_stable_id (s_con_n))) {
connection_clean_free = nm_simple_connection_new_clone (connection);
connection_clean = connection_clean_free;
s_con_n = nm_connection_get_setting_connection (connection);
g_object_set (s_con_n,
NM_SETTING_CONNECTION_ID, nm_setting_connection_get_id (s_con_a),
NM_SETTING_CONNECTION_UUID, nm_setting_connection_get_uuid (s_con_a),
NM_SETTING_CONNECTION_AUTOCONNECT, nm_setting_connection_get_autoconnect (s_con_a),
NM_SETTING_CONNECTION_STABLE_ID, nm_setting_connection_get_stable_id (s_con_a),
NULL);
}
}
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
con_old = applied_clone = nm_simple_connection_new_clone (applied);
con_new = applied;
device: avoid changing immutable properties during reapply We allow to reapply a connection with different id, uuid, stable-id, autoconnect value. This is allowed for convenience, so that a user can reapply a connection that differs in these fields. But actually, these fields cannot be reapplied. That is, their new values are not considered and the old values are continued to be used. Thus, mangle the reapplied connection to use the original, actually used values.
2017-01-10 20:07:23 +01:00
nm_connection_replace_settings_from_connection (applied, connection_clean);
device: clear secrets from applied connection during reapply The applied connection must have no secrets. It's unclear whether there are any secrets at this point (possibly). To be sure, clear them.
2016-04-30 12:34:17 +02:00
nm_connection_clear_secrets (applied);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
} else
con_old = con_new = applied;
device: on reapply reset commit_first_time flag Based on this flag, we decide that: - if we are not gonna commit the first time and the connection is configured with never-default, we would not remove a default route added externally. During a reapply, we however want to get rid of an externally configured default route.
2017-03-16 14:37:54 +01:00
priv->v4_commit_first_time = TRUE;
priv->v6_commit_first_time = TRUE;
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
/**************************************************************************
* Reapply changes
*************************************************************************/
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
klass->reapply_connection (self, con_old, con_new);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
nm_device_update_firewall_zone (self);
nm_device_update_metered (self);
device: reapply connection.lldp property
2017-03-06 17:48:01 +01:00
lldp_init (self, FALSE);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
s_ip4_old = nm_connection_get_setting_ip4_config (con_old);
s_ip4_new = nm_connection_get_setting_ip4_config (con_new);
s_ip6_old = nm_connection_get_setting_ip6_config (con_old);
s_ip6_new = nm_connection_get_setting_ip6_config (con_new);
device: force restart of IP method during reapply Scenario: Have a connection with DHCPv4 and a default-route. When externally removing the default route (`ip route delete 0.0.0.0/0`) and issuing `nmcli device reapply $IF`, the default route was not restored. That was because when externally removing the default route, we would remove the gateway from priv->con_ip4_config (see update_ip4_config()). Later, when reapplying the connection, the IP method doesn't actually change. So we would not restart DHCP and thus there is no gateway around to add the default route. The default route would only be restored after receiving a DHCP lease in the far future. Fix that, by always restarting the IP method.
2017-03-16 14:54:16 +01:00
nm_device_reactivate_ip4_config (self, s_ip4_old, s_ip4_new, TRUE);
nm_device_reactivate_ip6_config (self, s_ip6_old, s_ip6_new, TRUE);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
reactivate_proxy_config (self);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
return TRUE;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
}
device: fix taking over device after modifying external connection For externally managed interfaces, we create an in-memory connection and keep the device with sys-iface-state=external. When the user actively modifies the connection, we persist it to storage. But we also must take over managing the device. One problem is that nm_device_reapply() errors out if the device is still activating. It's unclear how to reapply the connection while the device is in the process of activation. So, if the user modifies the created connection very quickly, reapplying the settings will fail. https://bugzilla.redhat.com/show_bug.cgi?id=1462223
2017-06-16 13:06:26 +02:00
gboolean
nm_device_reapply (NMDevice *self,
NMConnection *connection,
GError **error)
{
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
return check_and_reapply_connection (self,
connection,
0,
NULL,
error);
}
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
typedef struct {
NMConnection *connection;
guint64 version_id;
} ReapplyData;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
static void
reapply_cb (NMDevice *self,
GDBusMethodInvocation *context,
NMAuthSubject *subject,
GError *error,
gpointer user_data)
{
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
ReapplyData *reapply_data = user_data;
guint64 version_id = 0;
gs_unref_object NMConnection *connection = NULL;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
GError *local = NULL;
device: add list of changed properties to reapply audit log
2017-03-04 00:21:22 +01:00
gs_free char *audit_args = NULL;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
if (reapply_data) {
connection = reapply_data->connection;
version_id = reapply_data->version_id;
g_slice_free (ReapplyData, reapply_data);
}
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
if (error) {
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_REAPPLY, self, FALSE, NULL, subject, error->message);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
g_dbus_method_invocation_return_gerror (context, error);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
return;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
}
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
if (!check_and_reapply_connection (self,
connection ? : (NMConnection *) nm_device_get_settings_connection (self),
version_id,
device: add list of changed properties to reapply audit log
2017-03-04 00:21:22 +01:00
&audit_args,
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
&local)) {
device: add list of changed properties to reapply audit log
2017-03-04 00:21:22 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_REAPPLY, self, FALSE, audit_args, subject, local->message);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_dbus_method_invocation_take_error (context, local);
local = NULL;
} else {
device: add list of changed properties to reapply audit log
2017-03-04 00:21:22 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_REAPPLY, self, TRUE, audit_args, subject, NULL);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_dbus_method_invocation_return_value (context, NULL);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
}
}
static void
impl_device_reapply (NMDevice *self,
GDBusMethodInvocation *context,
GVariant *settings,
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
guint64 version_id,
device: fix signature for @flags argument of impl_device_reapply() Thereby, also adjust the type for libnm's wrapper function -- as we already broke ABI.
2016-02-12 14:02:53 +01:00
guint32 flags)
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
{
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
NMSettingsConnection *settings_connection;
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
NMConnection *connection = NULL;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
GError *error = NULL;
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
ReapplyData *reapply_data;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
/* No flags supported as of now. */
if (flags != 0) {
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
error = g_error_new_literal (NM_DEVICE_ERROR,
device: fix signature for @flags argument of impl_device_reapply() Thereby, also adjust the type for libnm's wrapper function -- as we already broke ABI.
2016-02-12 14:02:53 +01:00
NM_DEVICE_ERROR_FAILED,
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
"Invalid flags specified");
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_REAPPLY, self, FALSE, NULL, context, error->message);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_dbus_method_invocation_take_error (context, error);
return;
}
if (priv->state != NM_DEVICE_STATE_ACTIVATED) {
error = g_error_new_literal (NM_DEVICE_ERROR,
NM_DEVICE_ERROR_NOT_ACTIVE,
"Device is not activated");
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_REAPPLY, self, FALSE, NULL, context, error->message);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_dbus_method_invocation_take_error (context, error);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
return;
}
settings_connection = nm_device_get_settings_connection (self);
g_return_if_fail (settings_connection);
if (settings && g_variant_n_children (settings)) {
/* New settings specified inline. */
core: be strict about connection argument for Reapply() D-Bus method There is no excuse for clients to send connections to NetworkManager that have invalid/unknown fields. Just reject them. As Reapply() is new API in nm-1-1, there is no problem with backward compatibility.
2016-03-23 15:50:20 +01:00
connection = _nm_simple_connection_new_from_dbus (settings,
NM_SETTING_PARSE_FLAGS_STRICT
| NM_SETTING_PARSE_FLAGS_NORMALIZE,
&error);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
if (!connection) {
g_prefix_error (&error, "The settings specified are invalid: ");
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_REAPPLY, self, FALSE, NULL, context, error->message);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_dbus_method_invocation_take_error (context, error);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
return;
}
nm_connection_clear_secrets (connection);
}
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
if (connection || version_id) {
reapply_data = g_slice_new (ReapplyData);
reapply_data->connection = connection;
reapply_data->version_id = version_id;
} else
reapply_data = NULL;
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
/* Ask the manager to authenticate this request for us */
g_signal_emit (self, signals[AUTH_REQUEST], 0,
context,
nm_device_get_applied_connection (self),
NM_AUTH_PERMISSION_NETWORK_CONTROL,
TRUE,
reapply_cb,
all: add version-id argument to device's Reapply method This breaks API and ABI for the functions related to Reapply, which got introduced in the current 1.1 development phase. The version-id is here to allow users to error out if the connection on the device was changed by a concurrent action. https://bugzilla.gnome.org/show_bug.cgi?id=761714
2016-02-11 09:04:58 +01:00
reapply_data);
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
}
core: add NMDevice's GetAppliedConnection D-Bus call Expose applied connection in D-Bus API. https://bugzilla.gnome.org/show_bug.cgi?id=760884
2016-02-11 09:18:35 +01:00
/*****************************************************************************/
static void
get_applied_connection_cb (NMDevice *self,
GDBusMethodInvocation *context,
NMAuthSubject *subject,
GError *error,
gpointer user_data /* possibly dangling pointer */)
{
NMDevicePrivate *priv;
NMConnection *applied_connection;
GVariant *settings;
g_return_if_fail (NM_IS_DEVICE (self));
if (error) {
g_dbus_method_invocation_return_gerror (context, error);
return;
}
priv = NM_DEVICE_GET_PRIVATE (self);
applied_connection = nm_device_get_applied_connection (self);
if (!applied_connection) {
error = g_error_new_literal (NM_DEVICE_ERROR,
NM_DEVICE_ERROR_NOT_ACTIVE,
"Device is not activated");
g_dbus_method_invocation_take_error (context, error);
return;
}
if (applied_connection != user_data) {
/* The applied connection changed due to a race. Reauthenticate. */
g_signal_emit (self, signals[AUTH_REQUEST], 0,
context,
applied_connection,
NM_AUTH_PERMISSION_NETWORK_CONTROL,
TRUE,
get_applied_connection_cb,
applied_connection /* no need take a ref. We will not dereference this pointer. */);
return;
}
settings = nm_connection_to_dbus (applied_connection, NM_CONNECTION_SERIALIZE_NO_SECRETS);
if (!settings)
settings = g_variant_new_array (G_VARIANT_TYPE ("{sa{sv}}"), NULL, 0);
g_dbus_method_invocation_return_value (context,
g_variant_new ("(@a{sa{sv}}t)",
settings,
nm_active_connection_version_id_get ((NMActiveConnection *) priv->act_request)));
}
static void
impl_device_get_applied_connection (NMDevice *self,
GDBusMethodInvocation *context,
guint32 flags)
{
NMConnection *applied_connection;
GError *error = NULL;
g_return_if_fail (NM_IS_DEVICE (self));
/* No flags supported as of now. */
if (flags != 0) {
error = g_error_new_literal (NM_DEVICE_ERROR,
NM_DEVICE_ERROR_FAILED,
"Invalid flags specified");
g_dbus_method_invocation_take_error (context, error);
return;
}
applied_connection = nm_device_get_applied_connection (self);
if (!applied_connection) {
error = g_error_new_literal (NM_DEVICE_ERROR,
NM_DEVICE_ERROR_NOT_ACTIVE,
"Device is not activated");
g_dbus_method_invocation_take_error (context, error);
return;
}
/* Ask the manager to authenticate this request for us */
g_signal_emit (self, signals[AUTH_REQUEST], 0,
context,
applied_connection,
NM_AUTH_PERMISSION_NETWORK_CONTROL,
TRUE,
get_applied_connection_cb,
applied_connection /* no need take a ref. We will not dereference this pointer. */);
}
/*****************************************************************************/
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
typedef struct {
gint64 timestamp_ms;
bool dirty;
} IP6RoutesTemporaryNotAvailableData;
static gboolean
_rt6_temporary_not_available_timeout (gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
priv->rt6_temporary_not_available_id = 0;
nm_device_activate_schedule_ip6_config_result (self);
return G_SOURCE_REMOVE;
}
static gboolean
_rt6_temporary_not_available_set (NMDevice *self,
GPtrArray *temporary_not_available)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
IP6RoutesTemporaryNotAvailableData *data;
GHashTableIter iter;
gint64 now_ms, oldest_ms;
const gint64 MAX_AGE_MS = 20000;
guint i;
gboolean success = TRUE;
if ( !temporary_not_available
|| !temporary_not_available->len) {
/* nothing outstanding. Clear tracking the routes. */
g_clear_pointer (&priv->rt6_temporary_not_available, g_hash_table_unref);
nm_clear_g_source (&priv->rt6_temporary_not_available_id);
return success;
}
if (priv->rt6_temporary_not_available) {
g_hash_table_iter_init (&iter, priv->rt6_temporary_not_available);
while (g_hash_table_iter_next (&iter, NULL, (gpointer *) &data))
data->dirty = TRUE;
} else {
priv->rt6_temporary_not_available = g_hash_table_new_full ((GHashFunc) nmp_object_id_hash,
(GEqualFunc) nmp_object_id_equal,
(GDestroyNotify) nmp_object_unref,
nm_g_slice_free_fcn (IP6RoutesTemporaryNotAvailableData));
}
now_ms = nm_utils_get_monotonic_timestamp_ms ();
oldest_ms = now_ms;
for (i = 0; i < temporary_not_available->len; i++) {
const NMPObject *o = temporary_not_available->pdata[i];
data = g_hash_table_lookup (priv->rt6_temporary_not_available, o);
if (data) {
if (!data->dirty)
continue;
data->dirty = FALSE;
nm_assert (data->timestamp_ms > 0 && data->timestamp_ms <= now_ms);
if (now_ms > data->timestamp_ms + MAX_AGE_MS) {
/* timeout. Could not add this address. */
_LOGW (LOGD_DEVICE, "failure to add IPv6 route: %s",
nmp_object_to_string (o, NMP_OBJECT_TO_STRING_PUBLIC, NULL, 0));
success = FALSE;
} else
oldest_ms = MIN (data->timestamp_ms, oldest_ms);
continue;
}
data = g_slice_new0 (IP6RoutesTemporaryNotAvailableData);
data->timestamp_ms = now_ms;
g_hash_table_insert (priv->rt6_temporary_not_available, (gpointer) nmp_object_ref (o), data);
}
g_hash_table_iter_init (&iter, priv->rt6_temporary_not_available);
while (g_hash_table_iter_next (&iter, NULL, (gpointer *) &data)) {
if (data->dirty)
g_hash_table_iter_remove (&iter);
}
nm_clear_g_source (&priv->rt6_temporary_not_available_id);
priv->rt6_temporary_not_available_id = g_timeout_add (oldest_ms + MAX_AGE_MS - now_ms,
_rt6_temporary_not_available_timeout,
self);
return success;
}
/*****************************************************************************/
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
disconnect_cb (NMDevice *self,
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
device: add audit support
2015-07-14 10:19:19 +02:00
NMAuthSubject *subject,
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
GError *error,
gpointer user_data)
core: implement manual disconnect feature In the past networkmanager did not allow to manually disconnect devices. Manually disconnected devices will not be automatically reconnected until one of the following events occur: 1. user activates a connection for the currently disconnected device 2. network manager awakes from hibernate/suspend 3. network manager is restarted (e.g. reboot) Add a Disconnect method to generic NMDevice dbus interface; set a new private autoconnect_inhibit flag if Disconnect method is called through dbus. Based on this auto activation for devices gets inhibited until one of the above events occur.
2009-09-16 13:18:24 +02:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
GError *local = NULL;
core: move nm_device_interface_disconnect() to nm-device.c
2011-11-17 23:44:17 -06:00
core: respect connection user permissions for activation/deactivation This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection
2014-01-17 11:18:23 -06:00
if (error) {
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
g_dbus_method_invocation_return_gerror (context, error);
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_DISCONNECT, self, FALSE, NULL, subject, error->message);
core: respect connection user permissions for activation/deactivation This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection
2014-01-17 11:18:23 -06:00
return;
}
core: track autoconnect for removed software devices (rh #1005913) When an interface is manually disconnected NM remembers that, and prevents automatic activation of the device. However, software devices are removed when they are disconnected, and thus the state of the device is lost. We need to track autoconnect outside the device - hash table of interface names not allowed to activate automatically. Without that the device would be auto-activated again and again, even if explicitly disconnected. Test case: $ nmcli con add type bond ifname bb con-name bb-con $ nmcli con add type bond-slave ifname em1 con-name b1-con master bb $ nmcli dev disconnect bb https://bugzilla.redhat.com/show_bug.cgi?id=1005913
2013-10-18 12:32:01 +02:00
core: respect connection user permissions for activation/deactivation This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection
2014-01-17 11:18:23 -06:00
/* Authorized */
if (priv->state <= NM_DEVICE_STATE_DISCONNECTED) {
local = g_error_new_literal (NM_DEVICE_ERROR,
NM_DEVICE_ERROR_NOT_ACTIVE,
"Device is not active");
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_DISCONNECT, self, FALSE, NULL, subject, local->message);
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
g_dbus_method_invocation_take_error (context, local);
core: respect connection user permissions for activation/deactivation This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection
2014-01-17 11:18:23 -06:00
} else {
device: improve tracking autoconnect-blocked flags of NMDevice - split NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN in two parts: "wrong-pin" and "manual-disconnect". Setting/unsetting them should be tracked differently, as their reason differs. - no longer initialize/clear the autoconnect-blocked reasons during realize/unrealize of the device. Instead, initialize it once when the object gets created (nm_device_init()), and keep the settings beyond unrealize/realize cycles. This only matters for software devices, as regular devices get deleted after unrealizing once. But for software devices it is essential, because we don't want to forget the autoconnect settings of the device instance. - drop verbose logging about blocking autoconnect due to failed pin. We already log changes to autoconnect-blocked flags with TRACE level. An additional message about this particular issue seems not necessary at INFO level. - in NMManager's do_sleep_wake(), no longer block autoconnect for devices during sleep. We already unmanage the device, which is a far more effective measure to prevent activation. We should not also block autoconnect.
2017-11-07 12:36:17 +01:00
nm_device_autoconnect_blocked_set (self, NM_DEVICE_AUTOCONNECT_BLOCKED_MANUAL_DISCONNECT);
core: track autoconnect for removed software devices (rh #1005913) When an interface is manually disconnected NM remembers that, and prevents automatic activation of the device. However, software devices are removed when they are disconnected, and thus the state of the device is lost. We need to track autoconnect outside the device - hash table of interface names not allowed to activate automatically. Without that the device would be auto-activated again and again, even if explicitly disconnected. Test case: $ nmcli con add type bond ifname bb con-name bb-con $ nmcli con add type bond-slave ifname em1 con-name b1-con master bb $ nmcli dev disconnect bb https://bugzilla.redhat.com/show_bug.cgi?id=1005913
2013-10-18 12:32:01 +02:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_state_changed (self,
devices: start using the DEACTIVATING state When a device is disconnected by the user (as opposed to due to network or hardware error, etc), set it first to DEACTIVATING, which does nothing but queue a transition to disconnected. This lets other parts of NM observe the device when it is about-to-disconnect, but still has an associated connection.
2014-01-03 13:58:05 -05:00
NM_DEVICE_STATE_DEACTIVATING,
core: respect connection user permissions for activation/deactivation This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection
2014-01-17 11:18:23 -06:00
NM_DEVICE_STATE_REASON_USER_REQUESTED);
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
g_dbus_method_invocation_return_value (context, NULL);
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_DISCONNECT, self, TRUE, NULL, subject, NULL);
core: move nm_device_interface_disconnect() to nm-device.c
2011-11-17 23:44:17 -06:00
}
core: implement manual disconnect feature In the past networkmanager did not allow to manually disconnect devices. Manually disconnected devices will not be automatically reconnected until one of the following events occur: 1. user activates a connection for the currently disconnected device 2. network manager awakes from hibernate/suspend 3. network manager is restarted (e.g. reboot) Add a Disconnect method to generic NMDevice dbus interface; set a new private autoconnect_inhibit flag if Disconnect method is called through dbus. Based on this auto activation for devices gets inhibited until one of the above events occur.
2009-09-16 13:18:24 +02:00
}
device: fix leaking queued NMActiveConnection The queued activation request must transition state to DEACTIVATED, otherwise it is not removed from the list of active_connections in NMManager.
2015-02-20 23:45:23 +01:00
static void
_clear_queued_act_request (NMDevicePrivate *priv)
{
if (priv->queued_act_request) {
active-connection: emit a StateChanged signal on state changes It includes a reason code that makes it possible for the clients to be more reasonable about error messages. The reason code is essentially copied from the VPN, plus three more reasons that were useful for non-VPN connections.
2017-03-05 15:30:24 +01:00
nm_active_connection_set_state ((NMActiveConnection *) priv->queued_act_request,
NM_ACTIVE_CONNECTION_STATE_DEACTIVATED,
NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_DISCONNECTED);
device: fix leaking queued NMActiveConnection The queued activation request must transition state to DEACTIVATED, otherwise it is not removed from the list of active_connections in NMManager.
2015-02-20 23:45:23 +01:00
g_clear_object (&priv->queued_act_request);
}
}
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
static void
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
impl_device_disconnect (NMDevice *self, GDBusMethodInvocation *context)
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
{
core: respect connection user permissions for activation/deactivation This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection
2014-01-17 11:18:23 -06:00
NMConnection *connection;
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
GError *error = NULL;
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
if (NM_DEVICE_GET_PRIVATE (self)->act_request == NULL) {
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
error = g_error_new_literal (NM_DEVICE_ERROR,
NM_DEVICE_ERROR_NOT_ACTIVE,
"This device is not active");
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
g_dbus_method_invocation_take_error (context, error);
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
return;
}
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
core: respect connection user permissions for activation/deactivation This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection
2014-01-17 11:18:23 -06:00
g_assert (connection);
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
/* Ask the manager to authenticate this request for us */
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_signal_emit (self, signals[AUTH_REQUEST], 0,
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
context,
core: respect connection user permissions for activation/deactivation This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection
2014-01-17 11:18:23 -06:00
connection,
core: re-implement device disconnect using generic auth request signal
2012-06-01 16:53:23 -05:00
NM_AUTH_PERMISSION_NETWORK_CONTROL,
TRUE,
disconnect_cb,
NULL);
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
}
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
delete_cb (NMDevice *self,
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
GDBusMethodInvocation *context,
device: add audit support
2015-07-14 10:19:19 +02:00
NMAuthSubject *subject,
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
GError *error,
gpointer user_data)
{
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
GError *local = NULL;
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
if (error) {
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
g_dbus_method_invocation_return_gerror (context, error);
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_DELETE, self, FALSE, NULL, subject, error->message);
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
return;
}
/* Authorized */
audit: add @args to device logging functions
2017-03-04 00:06:59 +01:00
nm_audit_log_device_op (NM_AUDIT_OP_DEVICE_DELETE, self, TRUE, NULL, subject, NULL);
core: add class function for device unrealization When a device is unrealized, its class-specific properties must also be cleared since the device is no longer valid.
2014-09-24 15:13:19 -05:00
if (nm_device_unrealize (self, TRUE, &local))
g_dbus_method_invocation_return_value (context, NULL);
else
g_dbus_method_invocation_take_error (context, local);
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
}
static void
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
impl_device_delete (NMDevice *self, GDBusMethodInvocation *context)
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
{
GError *error = NULL;
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
if (!nm_device_is_software (self) || !nm_device_is_real (self)) {
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
error = g_error_new_literal (NM_DEVICE_ERROR,
NM_DEVICE_ERROR_NOT_SOFTWARE,
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
"This device is not a software device or is not realized");
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
g_dbus_method_invocation_take_error (context, error);
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
return;
}
/* Ask the manager to authenticate this request for us */
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_signal_emit (self, signals[AUTH_REQUEST], 0,
device: add a new D-Bus 'Delete' method for removing software devices
2014-06-19 12:37:49 +02:00
context,
NULL,
NM_AUTH_PERMISSION_NETWORK_CONTROL,
TRUE,
delete_cb,
NULL);
}
core: don't activate failed queued activation requests If the queued activation request failed before the device is finished deactiving the old request, don't start activating the failed queued request.
2014-10-16 15:01:16 -05:00
static gboolean
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
_device_activate (NMDevice *self, NMActRequest *req)
2007-09-14 Dan Williams <dcbw@redhat.com> Implement deferred activation support in the device class. * src/nm-device-interface.c src/nm-device-interface.h - (nm_device_interface_activate): take more arguments to support deferred activation; callers must pass one of (connection) OR (service_name, connection_path) - (impl_device_activate): connection validation is punted to the device to be able to handle deferred activation. Yes, this means errors don't get returned from the Activate() dbus call, and yes, that should be fixed somehow later. * src/nm-device.c src/nm-device.h - (clear_act_request): clear additional deferred activation stuff too - (deferred_activation_timeout_cb): new function; clean up when deferred activation times out. - (deferred_activation_start_cb): new function; when the connection finally becomes available, start device activation - (nm_device_activate): attach to the right signals of the activation request if we need to defer activation until the connection is valid * src/NetworkManagerPolicy.c - (nm_policy_device_change_check): update for additional arguments required for nm_device_interface_activate(). Pass NULL for these though because this function already knows exactly which NMConnection to use git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2812 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-14 19:51:04 +00:00
{
core: move nm_device_interface_activate() to nm-device.c
2011-11-17 23:50:13 -06:00
NMDevicePrivate *priv;
NMConnection *connection;
core: don't activate failed queued activation requests If the queued activation request failed before the device is finished deactiving the old request, don't start activating the failed queued request.
2014-10-16 15:01:16 -05:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
g_return_val_if_fail (NM_IS_ACT_REQUEST (req), FALSE);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
g_return_val_if_fail (nm_device_get_managed (self, FALSE), FALSE);
core: don't activate failed queued activation requests If the queued activation request failed before the device is finished deactiving the old request, don't start activating the failed queued request.
2014-10-16 15:01:16 -05:00
/* Ensure the activation request is still valid; the master may have
* already failed in which case activation of this device should not proceed.
*/
if (nm_active_connection_get_state (NM_ACTIVE_CONNECTION (req)) >= NM_ACTIVE_CONNECTION_STATE_DEACTIVATING)
return FALSE;
core: move nm_device_interface_activate() to nm-device.c
2011-11-17 23:50:13 -06:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_act_request_get_applied_connection (req);
core: move nm_device_interface_activate() to nm-device.c
2011-11-17 23:50:13 -06:00
g_assert (connection);
device/logging: log connection UUID when activating connection It is often hard to understand whether we activate an assumed connection. Only the UUID is unique.
2015-04-17 15:46:17 +02:00
_LOGI (LOGD_DEVICE, "Activation: starting connection '%s' (%s)",
nm_connection_get_id (connection),
nm_connection_get_uuid (connection));
2007-09-14 Dan Williams <dcbw@redhat.com> Implement deferred activation support in the device class. * src/nm-device-interface.c src/nm-device-interface.h - (nm_device_interface_activate): take more arguments to support deferred activation; callers must pass one of (connection) OR (service_name, connection_path) - (impl_device_activate): connection validation is punted to the device to be able to handle deferred activation. Yes, this means errors don't get returned from the Activate() dbus call, and yes, that should be fixed somehow later. * src/nm-device.c src/nm-device.h - (clear_act_request): clear additional deferred activation stuff too - (deferred_activation_timeout_cb): new function; clean up when deferred activation times out. - (deferred_activation_start_cb): new function; when the connection finally becomes available, start device activation - (nm_device_activate): attach to the right signals of the activation request if we need to defer activation until the connection is valid * src/NetworkManagerPolicy.c - (nm_policy_device_change_check): update for additional arguments required for nm_device_interface_activate(). Pass NULL for these though because this function already knows exactly which NMConnection to use git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2812 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-14 19:51:04 +00:00
core: refactor delete_on_deactivate in nm-device Instead of only passing the ifindex to the callback, pack additional data. This allows for better logging by also writing the g_idle_add id which allows to associate the scheduling with cancel calls. Also, this fixes that the callback could not clear the @delete_on_deactivate_id of the device, so that a following delete_on_deactivate_unschedule() would think that there is still something to cancel. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:20:14 +01:00
delete_on_deactivate_unschedule (self);
core: unschedule deletion of software device when starting an activation request This fixes queued activation request to be aborted because the software device gets removed before the device reaches the PREPARED state. This happens, because when the previous connection disconnects, the device will schedule its removal. https://bugzilla.redhat.com/show_bug.cgi?id=1073015 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-05 22:07:19 +01:00
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
act_request_set (self, req);
2007-09-26 Dan Williams <dcbw@redhat.com> * src/nm-manager.c src/nm-manager.h src/nm-activation-request.c src/nm-activation-request.h - Move the GetSecrets stuff out of the NMManager instance because it doesn't really need to be there and complicates things * src/nm-device.c - (connection_secrets_failed_cb, device_activation_go): connect to the connection-secrets-failed signal and deactivate the device if the GetSecrets call fails * src/nm-device-802-11-wireless.c - (link_timeout_cb, supplicant_connection_timeout_cb, real_act_stage2_config, real_act_stage4_ip_config_timeout): request secrets and give correct hints about whether new secrets should be asked for by the client or not git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2899 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-27 04:52:03 +00:00
core: make assumed activations go through all the stages Assumed slave connections need to be added to their master devices, which didn't used to happen because the devices activating assumed connections jumped directly to stage3, bypassing all the master/slave handling stuff. Instead, make all assumed connections go through all activation stages, but make sure that things which touch the device don't get done for assumed connections. This requires moving the master/slave code out of the override-able class methods because we need to call the master/slave code for assumed connections, but we don't want to call the override-able class activation methods.
2013-11-07 01:08:02 -06:00
nm_device_activate_schedule_stage1_device_prepare (self);
core: don't activate failed queued activation requests If the queued activation request failed before the device is finished deactiving the old request, don't start activating the failed queued request.
2014-10-16 15:01:16 -05:00
return TRUE;
2007-09-14 Dan Williams <dcbw@redhat.com> Implement deferred activation support in the device class. * src/nm-device-interface.c src/nm-device-interface.h - (nm_device_interface_activate): take more arguments to support deferred activation; callers must pass one of (connection) OR (service_name, connection_path) - (impl_device_activate): connection validation is punted to the device to be able to handle deferred activation. Yes, this means errors don't get returned from the Activate() dbus call, and yes, that should be fixed somehow later. * src/nm-device.c src/nm-device.h - (clear_act_request): clear additional deferred activation stuff too - (deferred_activation_timeout_cb): new function; clean up when deferred activation times out. - (deferred_activation_start_cb): new function; when the connection finally becomes available, start device activation - (nm_device_activate): attach to the right signals of the activation request if we need to defer activation until the connection is valid * src/NetworkManagerPolicy.c - (nm_policy_device_change_check): update for additional arguments required for nm_device_interface_activate(). Pass NULL for these though because this function already knows exactly which NMConnection to use git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2812 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-14 19:51:04 +00:00
}
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
static void
_carrier_wait_check_queued_act_request (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMActRequest *queued_req;
if ( !priv->queued_act_request
|| !priv->queued_act_request_is_waiting_for_carrier)
return;
priv->queued_act_request_is_waiting_for_carrier = FALSE;
if (!priv->carrier) {
_LOGD (LOGD_DEVICE, "Cancel queued activation request as we have no carrier after timeout");
device: properly cancel queued activation request We would leak the NMActivationRequest when carrier didn't come within timeout. We must properly set the state of the activation request. https://bugzilla.redhat.com/show_bug.cgi?id=1079353 Fixes: 0bfe635119facb8514e8f5824f599f4c4c3514e2
2015-10-19 15:16:20 +02:00
_clear_queued_act_request (priv);
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
} else {
_LOGD (LOGD_DEVICE, "Activate queued activation request as we now have carrier");
queued_req = priv->queued_act_request;
priv->queued_act_request = NULL;
_device_activate (self, queued_req);
g_object_unref (queued_req);
}
}
static gboolean
_carrier_wait_check_act_request_must_queue (NMDevice *self, NMActRequest *req)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
/* If we have carrier or if we are not waiting for it, the activation
* request is not blocked waiting for carrier. */
if (priv->carrier)
return FALSE;
if (priv->carrier_wait_id == 0)
return FALSE;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_act_request_get_applied_connection (req);
device: don't wait for carrier when activating static connection When the connection to be activated doesn't require carrier, don't queue it to wait for it. https://bugzilla.redhat.com/show_bug.cgi?id=1079353 Fixes: 0bfe635119facb8514e8f5824f599f4c4c3514e2
2015-10-19 14:44:38 +02:00
if (!connection_requires_carrier (connection))
return FALSE;
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
if (!nm_device_check_connection_available (self, connection, NM_DEVICE_CHECK_CON_AVAILABLE_ALL, NULL)) {
/* We passed all @flags we have, and no @specific_object.
* This equals maximal availability, if a connection is not available
* in this case, it is not waiting for carrier.
*
* Actually, why are we even trying to activate it? Strange, but whatever
* the reason, don't wait for carrier.
*/
return FALSE;
}
if (nm_device_check_connection_available (self, connection, NM_DEVICE_CHECK_CON_AVAILABLE_ALL & ~_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_WAITING_CARRIER, NULL)) {
/* The connection was available with flags ALL, and it is still available
* if we pretend not to wait for carrier. That means that the
* connection is available now, and does not wait for carrier.
*
* Since the flags increase the availability of a connection, when checking
* ALL&~WAITING_CARRIER, it means that we certainly would wait for carrier. */
return FALSE;
}
/* The activation request must wait for carrier. */
return TRUE;
}
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
void
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
nm_device_steal_connection (NMDevice *self, NMSettingsConnection *connection)
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: downgrade logging warning in nm_device_steal_connection() <info> [1467793329.6313] device (veth-guest): Activation: starting connection 'my-wired' (ca058ec5-8a47-4e1e-b38e-962b71c4699e) <debug> [1467793329.6313] device[0x55af2884bf90] (veth-guest): activation-stage: schedule activate_stage1_device_prepare,2 (id 510) <warn> [1467793329.6314] device (veth-guest): disconnecting connection 'my-wired' for new activation request. <info> [1467793329.6315] device (veth-guest): state change: disconnected -> deactivating (reason 'new-activation') [30 110 60 A warning is too verbose. This is not an unusual condition, it's just that a new activation supersedes an other one.
2016-07-06 10:23:44 +02:00
_LOGI (LOGD_DEVICE, "disconnecting connection '%s' for new activation request",
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
nm_settings_connection_get_id (connection));
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
if ( priv->queued_act_request
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
&& connection == nm_active_connection_get_settings_connection (NM_ACTIVE_CONNECTION (priv->queued_act_request)))
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
_clear_queued_act_request (priv);
if ( priv->act_request
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
&& connection == nm_active_connection_get_settings_connection (NM_ACTIVE_CONNECTION (priv->act_request))
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
&& priv->state < NM_DEVICE_STATE_DEACTIVATING)
nm_device_state_changed (self,
NM_DEVICE_STATE_DEACTIVATING,
manager: use proper reason when stealing a connection The user-requested reason is not really appropriate and blocks autoreconnect. We added a new reason precisely for that. Fixes: 4cb97cf66f175857a1910ee926ea61dc507c08e8
2015-06-18 15:40:42 -04:00
NM_DEVICE_STATE_REASON_NEW_ACTIVATION);
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
}
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
void
nm_device_queue_activation (NMDevice *self, NMActRequest *req)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
gboolean must_queue;
must_queue = _carrier_wait_check_act_request_must_queue (self, req);
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
device: delay the activation if the backing device is not yet there
2016-03-23 14:51:53 +01:00
if (!priv->act_request && !must_queue && nm_device_is_real (self)) {
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
/* Just activate immediately */
core: don't activate failed queued activation requests If the queued activation request failed before the device is finished deactiving the old request, don't start activating the failed queued request.
2014-10-16 15:01:16 -05:00
if (!_device_activate (self, req))
g_assert_not_reached ();
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
return;
}
/* supercede any already-queued request */
device: fix leaking queued NMActiveConnection The queued activation request must transition state to DEACTIVATED, otherwise it is not removed from the list of active_connections in NMManager.
2015-02-20 23:45:23 +01:00
_clear_queued_act_request (priv);
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
priv->queued_act_request = g_object_ref (req);
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
priv->queued_act_request_is_waiting_for_carrier = must_queue;
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
_LOGD (LOGD_DEVICE, "queue activation request waiting for %s", must_queue ? "carrier" : "currently active connection to disconnect");
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
/* Deactivate existing activation request first */
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
if (priv->act_request) {
_LOGI (LOGD_DEVICE, "disconnecting for new activation request.");
nm_device_state_changed (self,
NM_DEVICE_STATE_DEACTIVATING,
device: use "new-activation" reason when deactivating for another activation "user-requested" has a side effect of disabling autoconnect. Fixes: 600489003ff2eca33865a3d41abcc9fc03fd6bb1
2015-02-17 10:40:18 +01:00
NM_DEVICE_STATE_REASON_NEW_ACTIVATION);
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
}
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
/*
* nm_device_is_activating
*
* Return whether or not the device is currently activating itself.
*
*/
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_is_activating (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: handle new device states The device states aren't used yet, but handle them anyway.
2011-03-17 13:39:31 -05:00
NMDeviceState state;
2007-09-20 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (nm_device_is_activating): work around a race between auto-activation and the user activating the same device that is being auto-activated git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2842 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-21 03:49:28 +00:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
state = nm_device_get_state (self);
core: handle new device states The device states aren't used yet, but handle them anyway.
2011-03-17 13:39:31 -05:00
if (state >= NM_DEVICE_STATE_PREPARE && state <= NM_DEVICE_STATE_SECONDARIES)
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
return TRUE;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-09-20 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (nm_device_is_activating): work around a race between auto-activation and the user activating the same device that is being auto-activated git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2842 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-09-21 03:49:28 +00:00
/* There's a small race between the time when stage 1 is scheduled
* and when the device actually sets STATE_PREPARE when the activation
* handler is actually run. If there's an activation handler scheduled
* we're activating anyway.
*/
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
return priv->act_handle4.id ? TRUE : FALSE;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
NMProxyConfig *
nm_device_get_proxy_config (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
return NM_DEVICE_GET_PRIVATE (self)->proxy_config;
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
static void
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
nm_device_set_proxy_config (NMDevice *self, const char *pac_url)
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
{
NMDevicePrivate *priv;
NMConnection *connection;
NMSettingProxy *s_proxy = NULL;
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
g_clear_object (&priv->proxy_config);
priv->proxy_config = nm_proxy_config_new ();
device: reapply proxy configuration In order to support a reapply of proxy configuration, remember the PAC URL received through DHCP and merge it again with configuration from proxy setting on reapply.
2017-03-07 14:34:17 +01:00
if (pac_url) {
nm_proxy_config_set_method (priv->proxy_config, NM_PROXY_CONFIG_METHOD_AUTO);
nm_proxy_config_set_pac_url (priv->proxy_config, pac_url);
_LOGD (LOGD_PROXY, "proxy: PAC url \"%s\"", pac_url);
} else
nm_proxy_config_set_method (priv->proxy_config, NM_PROXY_CONFIG_METHOD_NONE);
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
connection = nm_device_get_applied_connection (self);
if (connection)
s_proxy = nm_connection_get_setting_proxy (connection);
if (s_proxy)
nm_proxy_config_merge_setting (priv->proxy_config, s_proxy);
}
/* IP Configuration stuff */
libnm, core, cli, tui: fix the capitalization of various types GLib/Gtk have mostly settled on the convention that two-letter acronyms in type names remain all-caps (eg, "IO"), but longer acronyms become initial-caps-only (eg, "Tcp"). NM was inconsistent, with most long acronyms using initial caps only (Adsl, Cdma, Dcb, Gsm, Olpc, Vlan), but others using all caps (DHCP, PPP, PPPOE, VPN). Fix libnm and src/ to use initial-caps only for all three-or-more-letter-long acronyms (and update nmcli and nmtui for the libnm changes).
2014-06-26 13:44:36 -04:00
NMDhcp4Config *
2008-09-18 Dan Williams <dcbw@redhat.com> Implement support for honoring configured and automatic hostnames, and for setting the configured hostname. * introspection/nm-ip4-config.xml src/nm-ip4-config.c src/nm-ip4-config.h src/dhcp-manager/nm-dhcp-manager.c - Remove useless hostname property; it's not really part of the IPv4 config * introspection/nm-settings-system.xml libnm-glib/nm-dbus-settings-system.c libnm-glib/nm-dbus-settings-system.h - Add SetHostname() call to system settings D-Bus interface - Add Hostname property to system settings D-Bus interface - (nm_dbus_settings_system_save_hostname, nm_dbus_settings_system_get_hostname): implement * src/nm-device.c src/nm-device.h - (nm_device_get_dhcp4_config): implement * src/nm-manager.c src/nm-manager.h - Fetch and track system settings service hostname changes, and proxy the changes via a GObject property of the manager * system-settings/src/nm-system-config-interface.c system-settings/src/nm-system-config-interface.h - Replace nm_system_config_interface_supports_add() with a capabilities bitfield * system-settings/src/nm-system-config-error.c system-settings/src/nm-system-config-error.h - Add additional errors * system-settings/src/dbus-settings.c system-settings/src/dbus-settings.h - (get_property, nm_sysconfig_settings_class_init): add hostname property; first plugin returning a hostname wins - (impl_settings_add_connection): use plugin capabilities instead of nm_system_config_interface_supports_add() - (impl_settings_save_hostname): implement hostname saving * src/NetworkManagerPolicy.c - (lookup_thread_run_cb, lookup_thread_worker, lookup_thread_new, lookup_thread_die): implement an asynchronous hostname lookup thread which given an IPv4 address tries to look up the hostname for that address with reverse DNS - (get_best_device): split out best device code from update_routing_and_dns() - (update_etc_hosts): update /etc/hosts with the machine's new hostname to preserve the 127.0.0.1 reverse mapping that so many things require - (set_system_hostname): set a given hostname - (update_system_hostname): implement hostname policy; a configured hostname (from the system settings service) is used if available, otherwise an automatically determined hostname from DHCP, VPN, etc. If there was no automatically determined hostname, reverse DNS of the best device's IP address will be used, and as a last resort the hostname 'localhost.localdomain' is set. - (update_routing_and_dns): use get_best_device(); update the system hostname when the network config changes - (hostname_changed): update system hostname if the system settings service signals a hostname change - (nm_policy_new): list for system settings service hostname changes - (nm_policy_destroy): ensure that an in-progress hostname lookup thread gets told to die * system-settings/plugins/keyfile/plugin.c system-settings/plugins/ifcfg-suse/plugin.c - (get_property, sc_plugin_ifcfg_class_init): implement hostname and capabilities properties * system-settings/plugins/ifcfg-fedora/shvar.c - (svOpenFile): re-enable R/W access of ifcfg files since the plugin writes out /etc/sysconfig/network now * system-settings/plugins/ifcfg-fedora/plugin.c - (plugin_get_hostname): get hostname from /etc/sysconfig/network - (plugin_set_hostname): save hostname to /etc/sysconfig/network - (sc_network_changed_cb): handle changes to /etc/sysconfig/network - (sc_plugin_ifcfg_init): monitor /etc/sysconfig/network for changes - (get_property, set_property, sc_plugin_ifcfg_class_init): implement hostname get/set and capabilities get git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4077 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-09-18 15:16:44 +00:00
nm_device_get_dhcp4_config (NMDevice *self)
{
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
2008-09-18 Dan Williams <dcbw@redhat.com> Implement support for honoring configured and automatic hostnames, and for setting the configured hostname. * introspection/nm-ip4-config.xml src/nm-ip4-config.c src/nm-ip4-config.h src/dhcp-manager/nm-dhcp-manager.c - Remove useless hostname property; it's not really part of the IPv4 config * introspection/nm-settings-system.xml libnm-glib/nm-dbus-settings-system.c libnm-glib/nm-dbus-settings-system.h - Add SetHostname() call to system settings D-Bus interface - Add Hostname property to system settings D-Bus interface - (nm_dbus_settings_system_save_hostname, nm_dbus_settings_system_get_hostname): implement * src/nm-device.c src/nm-device.h - (nm_device_get_dhcp4_config): implement * src/nm-manager.c src/nm-manager.h - Fetch and track system settings service hostname changes, and proxy the changes via a GObject property of the manager * system-settings/src/nm-system-config-interface.c system-settings/src/nm-system-config-interface.h - Replace nm_system_config_interface_supports_add() with a capabilities bitfield * system-settings/src/nm-system-config-error.c system-settings/src/nm-system-config-error.h - Add additional errors * system-settings/src/dbus-settings.c system-settings/src/dbus-settings.h - (get_property, nm_sysconfig_settings_class_init): add hostname property; first plugin returning a hostname wins - (impl_settings_add_connection): use plugin capabilities instead of nm_system_config_interface_supports_add() - (impl_settings_save_hostname): implement hostname saving * src/NetworkManagerPolicy.c - (lookup_thread_run_cb, lookup_thread_worker, lookup_thread_new, lookup_thread_die): implement an asynchronous hostname lookup thread which given an IPv4 address tries to look up the hostname for that address with reverse DNS - (get_best_device): split out best device code from update_routing_and_dns() - (update_etc_hosts): update /etc/hosts with the machine's new hostname to preserve the 127.0.0.1 reverse mapping that so many things require - (set_system_hostname): set a given hostname - (update_system_hostname): implement hostname policy; a configured hostname (from the system settings service) is used if available, otherwise an automatically determined hostname from DHCP, VPN, etc. If there was no automatically determined hostname, reverse DNS of the best device's IP address will be used, and as a last resort the hostname 'localhost.localdomain' is set. - (update_routing_and_dns): use get_best_device(); update the system hostname when the network config changes - (hostname_changed): update system hostname if the system settings service signals a hostname change - (nm_policy_new): list for system settings service hostname changes - (nm_policy_destroy): ensure that an in-progress hostname lookup thread gets told to die * system-settings/plugins/keyfile/plugin.c system-settings/plugins/ifcfg-suse/plugin.c - (get_property, sc_plugin_ifcfg_class_init): implement hostname and capabilities properties * system-settings/plugins/ifcfg-fedora/shvar.c - (svOpenFile): re-enable R/W access of ifcfg files since the plugin writes out /etc/sysconfig/network now * system-settings/plugins/ifcfg-fedora/plugin.c - (plugin_get_hostname): get hostname from /etc/sysconfig/network - (plugin_set_hostname): save hostname to /etc/sysconfig/network - (sc_network_changed_cb): handle changes to /etc/sysconfig/network - (sc_plugin_ifcfg_init): monitor /etc/sysconfig/network for changes - (get_property, set_property, sc_plugin_ifcfg_class_init): implement hostname get/set and capabilities get git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4077 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-09-18 15:16:44 +00:00
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
return NM_DEVICE_GET_PRIVATE (self)->dhcp4.config;
2008-09-18 Dan Williams <dcbw@redhat.com> Implement support for honoring configured and automatic hostnames, and for setting the configured hostname. * introspection/nm-ip4-config.xml src/nm-ip4-config.c src/nm-ip4-config.h src/dhcp-manager/nm-dhcp-manager.c - Remove useless hostname property; it's not really part of the IPv4 config * introspection/nm-settings-system.xml libnm-glib/nm-dbus-settings-system.c libnm-glib/nm-dbus-settings-system.h - Add SetHostname() call to system settings D-Bus interface - Add Hostname property to system settings D-Bus interface - (nm_dbus_settings_system_save_hostname, nm_dbus_settings_system_get_hostname): implement * src/nm-device.c src/nm-device.h - (nm_device_get_dhcp4_config): implement * src/nm-manager.c src/nm-manager.h - Fetch and track system settings service hostname changes, and proxy the changes via a GObject property of the manager * system-settings/src/nm-system-config-interface.c system-settings/src/nm-system-config-interface.h - Replace nm_system_config_interface_supports_add() with a capabilities bitfield * system-settings/src/nm-system-config-error.c system-settings/src/nm-system-config-error.h - Add additional errors * system-settings/src/dbus-settings.c system-settings/src/dbus-settings.h - (get_property, nm_sysconfig_settings_class_init): add hostname property; first plugin returning a hostname wins - (impl_settings_add_connection): use plugin capabilities instead of nm_system_config_interface_supports_add() - (impl_settings_save_hostname): implement hostname saving * src/NetworkManagerPolicy.c - (lookup_thread_run_cb, lookup_thread_worker, lookup_thread_new, lookup_thread_die): implement an asynchronous hostname lookup thread which given an IPv4 address tries to look up the hostname for that address with reverse DNS - (get_best_device): split out best device code from update_routing_and_dns() - (update_etc_hosts): update /etc/hosts with the machine's new hostname to preserve the 127.0.0.1 reverse mapping that so many things require - (set_system_hostname): set a given hostname - (update_system_hostname): implement hostname policy; a configured hostname (from the system settings service) is used if available, otherwise an automatically determined hostname from DHCP, VPN, etc. If there was no automatically determined hostname, reverse DNS of the best device's IP address will be used, and as a last resort the hostname 'localhost.localdomain' is set. - (update_routing_and_dns): use get_best_device(); update the system hostname when the network config changes - (hostname_changed): update system hostname if the system settings service signals a hostname change - (nm_policy_new): list for system settings service hostname changes - (nm_policy_destroy): ensure that an in-progress hostname lookup thread gets told to die * system-settings/plugins/keyfile/plugin.c system-settings/plugins/ifcfg-suse/plugin.c - (get_property, sc_plugin_ifcfg_class_init): implement hostname and capabilities properties * system-settings/plugins/ifcfg-fedora/shvar.c - (svOpenFile): re-enable R/W access of ifcfg files since the plugin writes out /etc/sysconfig/network now * system-settings/plugins/ifcfg-fedora/plugin.c - (plugin_get_hostname): get hostname from /etc/sysconfig/network - (plugin_set_hostname): save hostname to /etc/sysconfig/network - (sc_network_changed_cb): handle changes to /etc/sysconfig/network - (sc_plugin_ifcfg_init): monitor /etc/sysconfig/network for changes - (get_property, set_property, sc_plugin_ifcfg_class_init): implement hostname get/set and capabilities get git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4077 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-09-18 15:16:44 +00:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
NMIP4Config *
nm_device_get_ip4_config (NMDevice *self)
{
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2008-03-11 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (nm_device_deactivate): don't need to munge DNS here; that gets done already in nm_device_set_ip4_config() - (handle_dhcp_lease_change): fail the device if setting the IP4Config due to a DHCP rebind fails - (nm_device_set_ip4_config): send property notifications when the ip4 config changes - (get_property): only report IP4Config property during valid states * src/NetworkManagerPolicy.c - (update_routing_and_dns): ignore devices that don't have an ip4 config; add parameter 'force_update' to allow callers to specify that changes should be made even if the default device doesn't change - (device_ip4_config_changed): update DNS and routing when the device's IP4Config changes, like for DHCP updates - (device_added): listen for ip4-config property changes git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3425 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-11 22:26:46 +00:00
return NM_DEVICE_GET_PRIVATE (self)->ip4_config;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
2008-11-07 Dan Williams <dcbw@redhat.com> Fix deletion of VPN gateway route on DHCP renew (bgo #558133) * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_ip4_route): return the route that was added - (nm_system_add_ip4_vpn_gateway_route): make add_vpn_gateway_route() public, clean up, and return the route that was added - (nm_system_apply_ip4_config): remove VPN related stuff to simplify, since nm_system_add_ip4_vpn_gateway_route() is now available; add flags to allow only certain attributes of the NMIP4Config to be applied * src/nm-device.c - (handle_dhcp_lease_change): don't touch the DHCP4 config on failure - (nm_device_set_ip4_config): use nm_ip4_config_diff() to only apply what's really changed between the old and new configs; don't export the new IP4 config on failure; always send the DNS info to the named manager * src/vpn-manager/nm-vpn-connection.c - (device_ip4_config_changed, nm_vpn_connection_new, dispose): track the parent device's IP4Config and re-add the VPN gateway route when it changes - (nm_vpn_connection_ip4_config_get): add the VPN gateway route (since nm_system_apply_ip4_config() no longer does) and cache it for later - (connection_state_changed): move cleanup code to its own function - (vpn_cleanup): delete any previously added VPN gateway route; and re-apply the parent device's addresses and routes using nm_system_apply_ip4_config(), not nm_device_set_ip4_config() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4277 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-07 13:57:39 +00:00
static gboolean
nm_device_set_ip4_config (NMDevice *self,
NMIP4Config *new_config,
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
gboolean commit,
GPtrArray *ip4_dev_route_blacklist)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
NMDevicePrivate *priv;
2008-11-07 Dan Williams <dcbw@redhat.com> Fix deletion of VPN gateway route on DHCP renew (bgo #558133) * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_ip4_route): return the route that was added - (nm_system_add_ip4_vpn_gateway_route): make add_vpn_gateway_route() public, clean up, and return the route that was added - (nm_system_apply_ip4_config): remove VPN related stuff to simplify, since nm_system_add_ip4_vpn_gateway_route() is now available; add flags to allow only certain attributes of the NMIP4Config to be applied * src/nm-device.c - (handle_dhcp_lease_change): don't touch the DHCP4 config on failure - (nm_device_set_ip4_config): use nm_ip4_config_diff() to only apply what's really changed between the old and new configs; don't export the new IP4 config on failure; always send the DNS info to the named manager * src/vpn-manager/nm-vpn-connection.c - (device_ip4_config_changed, nm_vpn_connection_new, dispose): track the parent device's IP4Config and re-add the VPN gateway route when it changes - (nm_vpn_connection_ip4_config_get): add the VPN gateway route (since nm_system_apply_ip4_config() no longer does) and cache it for later - (connection_state_changed): move cleanup code to its own function - (vpn_cleanup): delete any previously added VPN gateway route; and re-apply the parent device's addresses and routes using nm_system_apply_ip4_config(), not nm_device_set_ip4_config() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4277 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-07 13:57:39 +00:00
NMIP4Config *old_config = NULL;
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
gboolean has_changes = FALSE;
2008-11-07 Dan Williams <dcbw@redhat.com> Fix deletion of VPN gateway route on DHCP renew (bgo #558133) * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_ip4_route): return the route that was added - (nm_system_add_ip4_vpn_gateway_route): make add_vpn_gateway_route() public, clean up, and return the route that was added - (nm_system_apply_ip4_config): remove VPN related stuff to simplify, since nm_system_add_ip4_vpn_gateway_route() is now available; add flags to allow only certain attributes of the NMIP4Config to be applied * src/nm-device.c - (handle_dhcp_lease_change): don't touch the DHCP4 config on failure - (nm_device_set_ip4_config): use nm_ip4_config_diff() to only apply what's really changed between the old and new configs; don't export the new IP4 config on failure; always send the DNS info to the named manager * src/vpn-manager/nm-vpn-connection.c - (device_ip4_config_changed, nm_vpn_connection_new, dispose): track the parent device's IP4Config and re-add the VPN gateway route when it changes - (nm_vpn_connection_ip4_config_get): add the VPN gateway route (since nm_system_apply_ip4_config() no longer does) and cache it for later - (connection_state_changed): move cleanup code to its own function - (vpn_cleanup): delete any previously added VPN gateway route; and re-apply the parent device's addresses and routes using nm_system_apply_ip4_config(), not nm_device_set_ip4_config() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4277 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-07 13:57:39 +00:00
gboolean success = TRUE;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
_LOGD (LOGD_IP4, "ip4-config: update (commit=%d, new-config=%p)",
commit, new_config);
device: improve logging when changing IP configuration nm_device_set_ip4_config() is called during cleanup and from ip4_config_merge_and_apply(). The latter, has several call sites. It's not easy to track whether we called set_ip4_config with or without commit (and if we call it without commit, we might not see a logging line at all). (same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
2016-04-15 20:07:02 +02:00
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
nm_assert ( !new_config
|| ( new_config
device: workaround coverity warning Coverity doesn't like this. Refactor a bit, hoping that it fares better. 1. Defect type: ASSERT_SIDE_EFFECT 1. NetworkManager-1.9.2/src/devices/nm-device.c:10226: assignment_where_comparison_intended: Assignment "ip_ifindex = nm_device_get_ip_ifindex(self)" has a side effect. This code will work differently in a non-debug build. 2. NetworkManager-1.9.2/src/devices/nm-device.c:10226: remediation: Did you intend to use a comparison ("==") instead?
2017-10-30 16:27:19 +01:00
&& ({
int ip_ifindex = nm_device_get_ip_ifindex (self);
( ip_ifindex > 0
&& ip_ifindex == nm_ip4_config_get_ifindex (new_config));
})));
2007-02-16 Tambet Ingo <tambet@ximian.com> * introspection/nm-ip4-config.xml: Implement. * libnm-glib/libnm-glib-test.c: Use new DBUS API in tests. * libnm-glib/nm-ip4-config.c: * libnm-glib/nm-ip4-config.c: Implement. * src/nm-ap-security[-*]: Remove circular dependencies between APs and AP securities. APs reference security. * src/nm-device-802-11-wireless.c: Implement missing properties that need to be exported over DBUS. * src/nm-device-802-3-ethernet.c: Ditto. * src/NetworkManagerAP.c: * src/NetworkManagerAP.h: - Convert to GObject, export over DBUS. * src/nm-ip4-config.h: * src/nm-ip4-config.h: - Convert to GObject, export over DBUS. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2322 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-16 11:23:49 +00:00
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: pass ifindex as parameter to nm_ip4_config_new()
2015-02-20 16:31:10 -06:00
2008-11-07 Dan Williams <dcbw@redhat.com> Fix deletion of VPN gateway route on DHCP renew (bgo #558133) * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_ip4_route): return the route that was added - (nm_system_add_ip4_vpn_gateway_route): make add_vpn_gateway_route() public, clean up, and return the route that was added - (nm_system_apply_ip4_config): remove VPN related stuff to simplify, since nm_system_add_ip4_vpn_gateway_route() is now available; add flags to allow only certain attributes of the NMIP4Config to be applied * src/nm-device.c - (handle_dhcp_lease_change): don't touch the DHCP4 config on failure - (nm_device_set_ip4_config): use nm_ip4_config_diff() to only apply what's really changed between the old and new configs; don't export the new IP4 config on failure; always send the DNS info to the named manager * src/vpn-manager/nm-vpn-connection.c - (device_ip4_config_changed, nm_vpn_connection_new, dispose): track the parent device's IP4Config and re-add the VPN gateway route when it changes - (nm_vpn_connection_ip4_config_get): add the VPN gateway route (since nm_system_apply_ip4_config() no longer does) and cache it for later - (connection_state_changed): move cleanup code to its own function - (vpn_cleanup): delete any previously added VPN gateway route; and re-apply the parent device's addresses and routes using nm_system_apply_ip4_config(), not nm_device_set_ip4_config() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4277 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-07 13:57:39 +00:00
old_config = priv->ip4_config;
2008-03-10 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (handle_dhcp_lease_change): apply an IP4 config to a device in response to a DHCP lease change - (dhcp_state_changed): handle DHCP lease changes while activated - (nm_device_set_ip4_config): remove a previously set named config when setting an ip4 config git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3417 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-11 02:46:35 +00:00
core: always commit ip[46]-config to nm-platform This is necessary to update the address lifetimes.
2013-07-02 22:22:57 +02:00
/* Always commit to nm-platform to update lifetimes */
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
if (commit && new_config) {
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
_commit_mtu (self, new_config);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
success = nm_ip4_config_commit (new_config,
libnm,core: add TABLE attribute for routes settings https://bugzilla.redhat.com/show_bug.cgi?id=1436531
2017-09-13 17:42:41 +02:00
nm_device_get_platform (self),
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
nm_device_get_route_table (self, AF_INET, FALSE)
? NM_IP_ROUTE_TABLE_SYNC_MODE_FULL
: NM_IP_ROUTE_TABLE_SYNC_MODE_MAIN);
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
nm_platform_ip4_dev_route_blacklist_set (nm_device_get_platform (self),
nm_ip4_config_get_ifindex (new_config),
ip4_dev_route_blacklist);
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
2008-11-07 Dan Williams <dcbw@redhat.com> Fix deletion of VPN gateway route on DHCP renew (bgo #558133) * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_ip4_route): return the route that was added - (nm_system_add_ip4_vpn_gateway_route): make add_vpn_gateway_route() public, clean up, and return the route that was added - (nm_system_apply_ip4_config): remove VPN related stuff to simplify, since nm_system_add_ip4_vpn_gateway_route() is now available; add flags to allow only certain attributes of the NMIP4Config to be applied * src/nm-device.c - (handle_dhcp_lease_change): don't touch the DHCP4 config on failure - (nm_device_set_ip4_config): use nm_ip4_config_diff() to only apply what's really changed between the old and new configs; don't export the new IP4 config on failure; always send the DNS info to the named manager * src/vpn-manager/nm-vpn-connection.c - (device_ip4_config_changed, nm_vpn_connection_new, dispose): track the parent device's IP4Config and re-add the VPN gateway route when it changes - (nm_vpn_connection_ip4_config_get): add the VPN gateway route (since nm_system_apply_ip4_config() no longer does) and cache it for later - (connection_state_changed): move cleanup code to its own function - (vpn_cleanup): delete any previously added VPN gateway route; and re-apply the parent device's addresses and routes using nm_system_apply_ip4_config(), not nm_device_set_ip4_config() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4277 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-07 13:57:39 +00:00
if (new_config) {
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
if (old_config) {
/* has_changes is set only on relevant changes, because when the configuration changes,
* this causes a re-read and reset. This should only happen for relevant changes */
nm_ip4_config_replace (old_config, new_config, &has_changes);
if (has_changes) {
device: improve logging when changing IP configuration nm_device_set_ip4_config() is called during cleanup and from ip4_config_merge_and_apply(). The latter, has several call sites. It's not easy to track whether we called set_ip4_config with or without commit (and if we call it without commit, we might not see a logging line at all). (same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
2016-04-15 20:07:02 +02:00
_LOGD (LOGD_IP4, "ip4-config: update IP4Config instance (%s)",
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
nm_exported_object_get_path (NM_EXPORTED_OBJECT (old_config)));
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
}
} else {
has_changes = TRUE;
priv->ip4_config = g_object_ref (new_config);
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
if (success && !nm_exported_object_is_exported (NM_EXPORTED_OBJECT (new_config)))
nm_exported_object_export (NM_EXPORTED_OBJECT (new_config));
core: add debug logging when setting IP[46]Config instance of a NMDevice Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-17 20:36:48 +01:00
device: improve logging when changing IP configuration nm_device_set_ip4_config() is called during cleanup and from ip4_config_merge_and_apply(). The latter, has several call sites. It's not easy to track whether we called set_ip4_config with or without commit (and if we call it without commit, we might not see a logging line at all). (same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
2016-04-15 20:07:02 +02:00
_LOGD (LOGD_IP4, "ip4-config: set IP4Config instance (%s)",
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
nm_exported_object_get_path (NM_EXPORTED_OBJECT (new_config)));
2008-11-07 Dan Williams <dcbw@redhat.com> Fix deletion of VPN gateway route on DHCP renew (bgo #558133) * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_ip4_route): return the route that was added - (nm_system_add_ip4_vpn_gateway_route): make add_vpn_gateway_route() public, clean up, and return the route that was added - (nm_system_apply_ip4_config): remove VPN related stuff to simplify, since nm_system_add_ip4_vpn_gateway_route() is now available; add flags to allow only certain attributes of the NMIP4Config to be applied * src/nm-device.c - (handle_dhcp_lease_change): don't touch the DHCP4 config on failure - (nm_device_set_ip4_config): use nm_ip4_config_diff() to only apply what's really changed between the old and new configs; don't export the new IP4 config on failure; always send the DNS info to the named manager * src/vpn-manager/nm-vpn-connection.c - (device_ip4_config_changed, nm_vpn_connection_new, dispose): track the parent device's IP4Config and re-add the VPN gateway route when it changes - (nm_vpn_connection_ip4_config_get): add the VPN gateway route (since nm_system_apply_ip4_config() no longer does) and cache it for later - (connection_state_changed): move cleanup code to its own function - (vpn_cleanup): delete any previously added VPN gateway route; and re-apply the parent device's addresses and routes using nm_system_apply_ip4_config(), not nm_device_set_ip4_config() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4277 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-07 13:57:39 +00:00
}
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
} else if (old_config) {
has_changes = TRUE;
priv->ip4_config = NULL;
device: improve logging when changing IP configuration nm_device_set_ip4_config() is called during cleanup and from ip4_config_merge_and_apply(). The latter, has several call sites. It's not easy to track whether we called set_ip4_config with or without commit (and if we call it without commit, we might not see a logging line at all). (same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
2016-04-15 20:07:02 +02:00
_LOGD (LOGD_IP4, "ip4-config: clear IP4Config instance (%s)",
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
nm_exported_object_get_path (NM_EXPORTED_OBJECT (old_config)));
core: combine and apply IPv4 configs instead of applying directly Like IPv6, keep the DHCP/LLv4 config separate and combine it with the NMSettingIP4Config to arrive at the final, combined IP4 config. This brings the behavior in line with IPv6 code flow and will allow adding the VPN routes config into the mix more easily.
2013-08-01 10:34:46 -05:00
/* Device config is invalid if combined config is invalid */
g_clear_object (&priv->dev_ip4_config);
2008-11-07 Dan Williams <dcbw@redhat.com> Fix deletion of VPN gateway route on DHCP renew (bgo #558133) * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_ip4_route): return the route that was added - (nm_system_add_ip4_vpn_gateway_route): make add_vpn_gateway_route() public, clean up, and return the route that was added - (nm_system_apply_ip4_config): remove VPN related stuff to simplify, since nm_system_add_ip4_vpn_gateway_route() is now available; add flags to allow only certain attributes of the NMIP4Config to be applied * src/nm-device.c - (handle_dhcp_lease_change): don't touch the DHCP4 config on failure - (nm_device_set_ip4_config): use nm_ip4_config_diff() to only apply what's really changed between the old and new configs; don't export the new IP4 config on failure; always send the DNS info to the named manager * src/vpn-manager/nm-vpn-connection.c - (device_ip4_config_changed, nm_vpn_connection_new, dispose): track the parent device's IP4Config and re-add the VPN gateway route when it changes - (nm_vpn_connection_ip4_config_get): add the VPN gateway route (since nm_system_apply_ip4_config() no longer does) and cache it for later - (connection_state_changed): move cleanup code to its own function - (vpn_cleanup): delete any previously added VPN gateway route; and re-apply the parent device's addresses and routes using nm_system_apply_ip4_config(), not nm_device_set_ip4_config() git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@4277 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-11-07 13:57:39 +00:00
}
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
concheck_periodic_update (self);
device: apply a loose IPv4 rp_filter when it would interfere with multihoming The IPv4 Strict Reverse Path Forwarding filter (RFC 3704) drops legitimate traffic when the same route is present on multiple interfaces, which is a pretty common scenario for IPv4 hosts. In particular, if the traffic is routable via multiple interfaces it drops traffic incoming via the device that has lower metric on the route to the originating network. Among other things, this disrupts existing connection when the user connected to the Internet via Wi-Fi activates a Wired Ethernet connection that also has a default route. Also, the Strict filter (and Reverse Path filters in general) provide practically no value to hosts that have a default route. The solution this patch uses is to detect scenarios where Strict filter is known to interfere and switch to a saner RP filter on the affected links. Routes to the same network on multiple interfaces is a good indication the RP filter would drop the legitimate traffice from the link with a lower metric. This includes the default routes. In such cases, we switch to the Loose Reverse Path Forwarding. This addresses the problems the multihomed hosts face, at the cost of disabling filtering altogether when a default route is present. A Feasible Path Reverse Path Forwarding would address the main problems with the Strict filter, but it's not implemented by the Linux kernel.
2017-03-16 14:27:03 +00:00
if (!nm_device_sys_iface_state_is_external_or_assume (self))
ip4_rp_filter_update (self);
policy: add manager for default routes and support multiple default routes Up to now, NMPolicy would iterate over all devices to find the "best" device and assign the default route to that device. A better approach is to add a default route to *all* devices that are never-default=no. The relative priority is choosen according to the route metrics. If two devices receive the same metric, we want to prefer the device that activates first. That way, the default route sticks to the same device until a better device activates or the device deactivates. Hence, the order of activation is imporant in this case (as it is already now). Also, if several devices have identical metrics, increment their metrics so that every metric is unique. This makes the routing deterministic according to what we choose as best device. A special case is assumed devices. In this case we cannot adjust the metric in face of equal metrics. Add a new singleton class NMDefaultRouteManager that has a list of all devices and their default routes. The manager will order the devices by their priority and configure the routes using platform. Also update the metric for VPN connections. Later we will track VPN routes also via NMDefaultRouteManager. For now, fix the VPN metric because otherwise VPNs would always get metric 1024 (which is usually much larger then the device metrics). https://bugzilla.gnome.org/show_bug.cgi?id=735512 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-29 00:03:47 +02:00
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
if (has_changes) {
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
NMSettingsConnection *settings_connection;
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
_update_ip4_address (self);
if (old_config != priv->ip4_config)
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IP4_CONFIG);
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
g_signal_emit (self, signals[IP4_CONFIG_CHANGED], 0, priv->ip4_config, old_config);
core: explicitly unexport objects when we're done with them Previously most objects were implicitly unexported when they were destroyed, but since refcounts may make the object live longer than intended, we should explicitly unexport them when they should no longer be present on the bus. This means we can assume that objects will always be un-exported already when they are destroyed, *except* when quitting where most objects will live until exit because NM leaves interfaces up and running on quit.
2015-07-23 10:03:21 -05:00
if (old_config != priv->ip4_config)
nm_exported_object_clear_and_unexport (&old_config);
devices: update generated connections when the underlying IP config changes If the IP config changes on a device that has assumed a generated connection, then update the connection's NMSettingIP4Config / NMSettingIP6Config, under the assumption that the configuration of that device was in progress but incomplete when NM first observed it.
2014-05-27 16:42:19 -04:00
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if ( nm_device_sys_iface_state_is_external (self)
&& (settings_connection = nm_device_get_settings_connection (self))
&& nm_settings_connection_get_nm_generated (settings_connection)
&& nm_active_connection_get_activation_type (NM_ACTIVE_CONNECTION (priv->act_request)) == NM_ACTIVATION_TYPE_EXTERNAL) {
devices: update generated connections when the underlying IP config changes If the IP config changes on a device that has assumed a generated connection, then update the connection's NMSettingIP4Config / NMSettingIP6Config, under the assumption that the configuration of that device was in progress but incomplete when NM first observed it.
2014-05-27 16:42:19 -04:00
NMSetting *s_ip4;
device: fix regenerating IP settings for assumed connections Fixes: 06da3532428e3498c1e808ff8be1af48b540a6ff
2015-10-11 20:31:47 +02:00
g_object_freeze_notify (G_OBJECT (settings_connection));
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
nm_connection_remove_setting (NM_CONNECTION (settings_connection), NM_TYPE_SETTING_IP4_CONFIG);
device: fix regenerating IP settings for assumed connections Fixes: 06da3532428e3498c1e808ff8be1af48b540a6ff
2015-10-11 20:31:47 +02:00
s_ip4 = nm_ip4_config_create_setting (priv->ip4_config);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
nm_connection_add_setting (NM_CONNECTION (settings_connection), s_ip4);
device: fix regenerating IP settings for assumed connections Fixes: 06da3532428e3498c1e808ff8be1af48b540a6ff
2015-10-11 20:31:47 +02:00
g_object_thaw_notify (G_OBJECT (settings_connection));
devices: update generated connections when the underlying IP config changes If the IP config changes on a device that has assumed a generated connection, then update the connection's NMSettingIP4Config / NMSettingIP6Config, under the assumption that the configuration of that device was in progress but incomplete when NM first observed it.
2014-05-27 16:42:19 -04:00
}
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
nm_device_queue_recheck_assume (self);
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
}
core: add device IPv4 and IPv6 config change signals We'll use these later to pull the DNS manager code out of the device class and into the policy.
2012-05-29 09:56:50 -05:00
2007-12-06 Tambet Ingo <tambet@gmail.com> * src/NetworkManagerSystem.c * (nm_system_device_set_from_ip4_config): Change the arguments: This whole file shouldn't really know anything about NMDevices, it should deal only with device interfaces. Devices might have different ifaces for different stuff and this place shouldn't know anything about it. * src/NetworkManagerPolicy.c: Get rid of leftover global * variable global_policy. (global_state_changed): Implement. In the current NM it's not really important, but will be required in the case of multiple active devices. (Or even better, if stuff like that gets moved out from NM). * src/vpn-manager/nm-vpn-connection.c * (connection_state_changed): Don't call nm_system_device_set_from_ip4_config() directly, use nm_device_set_ip4_config() instead. * src/nm-device.c: Add a ip_face protected member. It's used for * 'multi-interface' devices like serial devices (ttyS0 and ppp0 for example). (nm_device_get_ip_iface): Implement. Default to the device iface if ip_iface is not set. (nm_device_set_ip_iface): Implement. (nm_device_activate_stage5_ip_config_commit): Move all the extra actions that happen after setting ip4_config from here ... (nm_device_set_ip4_config): ... to here. The reason behind it is that no other code than this function should call nm_system_device_set_from_ip4_config() because no other code has enough information on which arguments to use. So instead, other code could just set the new ip4 config using this function and everyone is happy. * src/nm-umts-device.c: Store the pending ids so that we can * remove pending actions if we happen to get deactivated while something is pending. (automatic_registration): Handle the response that indicates pending network registration and wait until the pending registration is done. (real_deactivate_quickly): If there's a pending operation, cancel it. * src/nm-serial-device.c (ppp_ip4_config): Set the ip_iface when * the iface is up ... (real_deactivate_quickly): ... and remove it when it's down. (nm_serial_device_get_reply): Return the timeout id so that the callers can remove it if needed. (nm_serial_device_wait_for_reply): Ditto. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3141 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-12-06 14:51:43 +00:00
return success;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
static gboolean
_replace_vpn_config_in_list (GSList **plist, GObject *old, GObject *new)
{
GSList *old_link;
device: don't assert the presence of old vpn configurations When a VPN connection is active and the parent device becomes unmanaged (due to device removal or system entering sleep), all configurations are removed from the interface and the device is taken down. After that, the VPN is disconnected and tries to remove the old VPN configuration from device, causing the following assertion to fail: _replace_vpn_config_in_list: assertion '!old' failed Remove the assertion as @old can be missing for valid reasons.
2016-03-07 18:14:30 +01:00
/* Below, assert that @new is not yet tracked, but still behave
* correctly in any case. Don't complain for missing @old since
* it could have been removed when the parent device became
* unmanaged. */
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
if ( old
&& (old_link = g_slist_find (*plist, old))) {
if (old != new) {
if (new)
old_link->data = g_object_ref (new);
else
device: fix leaking GSList element in _replace_vpn_config_in_list() Fixes: 9bbf5e94c2ff676f685a7740713140026efbcb7c
2016-03-08 10:26:27 +01:00
*plist = g_slist_delete_link (*plist, old_link);
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
g_object_unref (old);
}
return TRUE;
}
if (new) {
if (!g_slist_find (*plist, new))
*plist = g_slist_append (*plist, g_object_ref (new));
else
g_return_val_if_reached (TRUE);
return TRUE;
}
return FALSE;
}
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
void
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
nm_device_replace_vpn4_config (NMDevice *self, NMIP4Config *old, NMIP4Config *config)
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
vpn: fix ifindex of parent IP config in apply_parent_device_config() When creating the NMIP4Config/NMIP6Config instance, we must always use the right ifindex. That is the ifindex, on which we want to apply the config. It also means, that for device-based VPNs (those with priv->ip_ifindex set, like OpenVPN), the parent's config must have the ip-ifindex of the parent device. Not of the VPN's device. One effect of this bug is that in add_ip4_vpn_gateway_route() we resolve the route to the external gateway and only accept it if it's on the parent device. But since the ifindex of the config was wrong, we would accept route on the wrong interface. https://bugzilla.gnome.org/show_bug.cgi?id=787370
2017-09-07 10:22:10 +02:00
nm_assert (!old || NM_IS_IP4_CONFIG (old));
nm_assert (!config || NM_IS_IP4_CONFIG (config));
nm_assert (!old || nm_ip4_config_get_ifindex (old) == nm_device_get_ip_ifindex (self));
nm_assert (!config || nm_ip4_config_get_ifindex (config) == nm_device_get_ip_ifindex (self));
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
if (!_replace_vpn_config_in_list (&priv->vpn4_configs, (GObject *) old, (GObject *) config))
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
return;
/* NULL to use existing configs */
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
if (!ip4_config_merge_and_apply (self, TRUE))
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_IP4, "failed to set VPN routes for device");
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
}
wwan: split out WWAN IP4Config from device config We want to set the WWAN config last, to ensure that the configuration we use overwrites anything that pppd might have set, becuase it touches some stuff itself. That means we have to keep the WWAN config separate, since dev_ip4_config is used for DHCP and IPv4LL, which we always set first to ensure they these don't overwrite external, administrator added config (eg, priv->ext_ip4_config). This also synchronizes the IPv4 config path with the upcoming IPv6 config path.
2014-07-15 17:16:56 -05:00
void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_set_wwan_ip4_config (NMDevice *self, NMIP4Config *config)
wwan: split out WWAN IP4Config from device config We want to set the WWAN config last, to ensure that the configuration we use overwrites anything that pppd might have set, becuase it touches some stuff itself. That means we have to keep the WWAN config separate, since dev_ip4_config is used for DHCP and IPv4LL, which we always set first to ensure they these don't overwrite external, administrator added config (eg, priv->ext_ip4_config). This also synchronizes the IPv4 config path with the upcoming IPv6 config path.
2014-07-15 17:16:56 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
wwan: split out WWAN IP4Config from device config We want to set the WWAN config last, to ensure that the configuration we use overwrites anything that pppd might have set, becuase it touches some stuff itself. That means we have to keep the WWAN config separate, since dev_ip4_config is used for DHCP and IPv4LL, which we always set first to ensure they these don't overwrite external, administrator added config (eg, priv->ext_ip4_config). This also synchronizes the IPv4 config path with the upcoming IPv6 config path.
2014-07-15 17:16:56 -05:00
if (priv->wwan_ip4_config == config)
return;
g_clear_object (&priv->wwan_ip4_config);
if (config)
priv->wwan_ip4_config = g_object_ref (config);
/* NULL to use existing configs */
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
if (!ip4_config_merge_and_apply (self, TRUE))
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_IP4, "failed to set WWAN IPv4 configuration");
wwan: split out WWAN IP4Config from device config We want to set the WWAN config last, to ensure that the configuration we use overwrites anything that pppd might have set, becuase it touches some stuff itself. That means we have to keep the WWAN config separate, since dev_ip4_config is used for DHCP and IPv4LL, which we always set first to ensure they these don't overwrite external, administrator added config (eg, priv->ext_ip4_config). This also synchronizes the IPv4 config path with the upcoming IPv6 config path.
2014-07-15 17:16:56 -05:00
}
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
static gboolean
nm_device_set_ip6_config (NMDevice *self,
NMIP6Config *new_config,
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
gboolean commit)
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
{
NMDevicePrivate *priv;
NMIP6Config *old_config = NULL;
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
gboolean has_changes = FALSE;
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
gboolean success = TRUE;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
_LOGD (LOGD_IP6, "ip6-config: update (commit=%d, new-config=%p)",
commit, new_config);
device: improve logging when changing IP configuration nm_device_set_ip4_config() is called during cleanup and from ip4_config_merge_and_apply(). The latter, has several call sites. It's not easy to track whether we called set_ip4_config with or without commit (and if we call it without commit, we might not see a logging line at all). (same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
2016-04-15 20:07:02 +02:00
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
nm_assert ( !new_config
|| ( new_config
device: workaround coverity warning Coverity doesn't like this. Refactor a bit, hoping that it fares better. 1. Defect type: ASSERT_SIDE_EFFECT 1. NetworkManager-1.9.2/src/devices/nm-device.c:10226: assignment_where_comparison_intended: Assignment "ip_ifindex = nm_device_get_ip_ifindex(self)" has a side effect. This code will work differently in a non-debug build. 2. NetworkManager-1.9.2/src/devices/nm-device.c:10226: remediation: Did you intend to use a comparison ("==") instead?
2017-10-30 16:27:19 +01:00
&& ({
int ip_ifindex = nm_device_get_ip_ifindex (self);
( ip_ifindex > 0
&& ip_ifindex == nm_ip6_config_get_ifindex (new_config));
})));
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: pass ifindex as parameter to nm_ip6_config_new()
2015-02-27 16:49:42 +01:00
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
old_config = priv->ip6_config;
core: always commit ip[46]-config to nm-platform This is necessary to update the address lifetimes.
2013-07-02 22:22:57 +02:00
/* Always commit to nm-platform to update lifetimes */
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
if (commit && new_config) {
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
gs_unref_ptrarray GPtrArray *temporary_not_available = NULL;
device: refactor configuring MTU by dropping mtu_desired Don't have this mtu_desired variable. All the data is readily available without redundancy. E.g. the applied-connection contains everything we need to know. Just get it as needed. Also drop apply_mtu_from_config(). It didn't take into account the MTU settings beside NMSettingWired. Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into priv->ip4_config. NMIP4Config now only tracks the MTU from the various non-user-config sources, but the user config is no longer merged back into the composite.
2017-01-15 13:38:33 +01:00
_commit_mtu (self, priv->ip4_config);
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
routes/trival: add argument @routes_full_sync to IP config commit The argument is still unused, so no behavioral change yet.
2015-07-13 19:20:08 +02:00
success = nm_ip6_config_commit (new_config,
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
nm_device_get_platform (self),
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
nm_device_get_route_table (self, AF_INET6, FALSE)
? NM_IP_ROUTE_TABLE_SYNC_MODE_FULL
: NM_IP_ROUTE_TABLE_SYNC_MODE_MAIN,
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
&temporary_not_available);
if (!_rt6_temporary_not_available_set (self, temporary_not_available))
success = FALSE;
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
}
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
if (new_config) {
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
if (old_config) {
/* has_changes is set only on relevant changes, because when the configuration changes,
* this causes a re-read and reset. This should only happen for relevant changes */
nm_ip6_config_replace (old_config, new_config, &has_changes);
if (has_changes) {
device: improve logging when changing IP configuration nm_device_set_ip4_config() is called during cleanup and from ip4_config_merge_and_apply(). The latter, has several call sites. It's not easy to track whether we called set_ip4_config with or without commit (and if we call it without commit, we might not see a logging line at all). (same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
2016-04-15 20:07:02 +02:00
_LOGD (LOGD_IP6, "ip6-config: update IP6Config instance (%s)",
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
nm_exported_object_get_path (NM_EXPORTED_OBJECT (old_config)));
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
}
} else {
has_changes = TRUE;
priv->ip6_config = g_object_ref (new_config);
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
if (success && !nm_exported_object_is_exported (NM_EXPORTED_OBJECT (new_config)))
nm_exported_object_export (NM_EXPORTED_OBJECT (new_config));
core: add debug logging when setting IP[46]Config instance of a NMDevice Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-03-17 20:36:48 +01:00
device: improve logging when changing IP configuration nm_device_set_ip4_config() is called during cleanup and from ip4_config_merge_and_apply(). The latter, has several call sites. It's not easy to track whether we called set_ip4_config with or without commit (and if we call it without commit, we might not see a logging line at all). (same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
2016-04-15 20:07:02 +02:00
_LOGD (LOGD_IP6, "ip6-config: set IP6Config instance (%s)",
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
nm_exported_object_get_path (NM_EXPORTED_OBJECT (new_config)));
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
} else if (old_config) {
has_changes = TRUE;
priv->ip6_config = NULL;
device: disable delegating prefixes to the device when the IPv6 config is removed Fixes a crash where the default DNS domain to be announced together with the prefixes to be delegated is updated at the same time the device is being unrealized. https://bugzilla.redhat.com/show_bug.cgi?id=1425818
2017-04-27 15:37:14 +02:00
priv->needs_ip6_subnet = FALSE;
device: improve logging when changing IP configuration nm_device_set_ip4_config() is called during cleanup and from ip4_config_merge_and_apply(). The latter, has several call sites. It's not easy to track whether we called set_ip4_config with or without commit (and if we call it without commit, we might not see a logging line at all). (same for nm_device_set_ip6_config()/ip6_config_merge_and_apply()).
2016-04-15 20:07:02 +02:00
_LOGD (LOGD_IP6, "ip6-config: clear IP6Config instance (%s)",
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
nm_exported_object_get_path (NM_EXPORTED_OBJECT (old_config)));
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
}
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
if (has_changes) {
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
NMSettingsConnection *settings_connection;
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
if (old_config != priv->ip6_config)
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IP6_CONFIG);
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
g_signal_emit (self, signals[IP6_CONFIG_CHANGED], 0, priv->ip6_config, old_config);
core: explicitly unexport objects when we're done with them Previously most objects were implicitly unexported when they were destroyed, but since refcounts may make the object live longer than intended, we should explicitly unexport them when they should no longer be present on the bus. This means we can assume that objects will always be un-exported already when they are destroyed, *except* when quitting where most objects will live until exit because NM leaves interfaces up and running on quit.
2015-07-23 10:03:21 -05:00
if (old_config != priv->ip6_config)
nm_exported_object_clear_and_unexport (&old_config);
devices: update generated connections when the underlying IP config changes If the IP config changes on a device that has assumed a generated connection, then update the connection's NMSettingIP4Config / NMSettingIP6Config, under the assumption that the configuration of that device was in progress but incomplete when NM first observed it.
2014-05-27 16:42:19 -04:00
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if ( nm_device_sys_iface_state_is_external (self)
&& (settings_connection = nm_device_get_settings_connection (self))
&& nm_settings_connection_get_nm_generated (settings_connection)
&& nm_active_connection_get_activation_type (NM_ACTIVE_CONNECTION (priv->act_request)) == NM_ACTIVATION_TYPE_EXTERNAL) {
devices: update generated connections when the underlying IP config changes If the IP config changes on a device that has assumed a generated connection, then update the connection's NMSettingIP4Config / NMSettingIP6Config, under the assumption that the configuration of that device was in progress but incomplete when NM first observed it.
2014-05-27 16:42:19 -04:00
NMSetting *s_ip6;
device: fix regenerating IP settings for assumed connections Fixes: 06da3532428e3498c1e808ff8be1af48b540a6ff
2015-10-11 20:31:47 +02:00
g_object_freeze_notify (G_OBJECT (settings_connection));
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
nm_connection_remove_setting (NM_CONNECTION (settings_connection), NM_TYPE_SETTING_IP6_CONFIG);
device: fix regenerating IP settings for assumed connections Fixes: 06da3532428e3498c1e808ff8be1af48b540a6ff
2015-10-11 20:31:47 +02:00
s_ip6 = nm_ip6_config_create_setting (priv->ip6_config);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
nm_connection_add_setting (NM_CONNECTION (settings_connection), s_ip6);
device: fix regenerating IP settings for assumed connections Fixes: 06da3532428e3498c1e808ff8be1af48b540a6ff
2015-10-11 20:31:47 +02:00
g_object_thaw_notify (G_OBJECT (settings_connection));
devices: update generated connections when the underlying IP config changes If the IP config changes on a device that has assumed a generated connection, then update the connection's NMSettingIP4Config / NMSettingIP6Config, under the assumption that the configuration of that device was in progress but incomplete when NM first observed it.
2014-05-27 16:42:19 -04:00
}
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
nm_device_queue_recheck_assume (self);
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
if (priv->ndisc)
ndisc_set_router_config (priv->ndisc, self);
core: update existing IP[46]Config of device instead of replacing it (bgo #707617) When the IP[46]Config changes, a new configuration gets assembled. Before, whenever the new configuration was different than the current one, the IP[46]Config of the device was completely replaced. This also meant, that the old dbus IP[46]Config object was removed and the new one was exported. Now instead of recreating a new configuration, it updates the existing (already exported) configuration in-place. Also, add new gobject properties 'gateway' and 'searches' to the config class, they will be exported over dbus. Also, whenever any of the exported properties changes, make sure that a notify signal gets emitted. https://bugzilla.gnome.org/show_bug.cgi?id=707617 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-09-06 11:56:41 +02:00
}
core: add device IPv4 and IPv6 config change signals We'll use these later to pull the DNS manager code out of the device class and into the policy.
2012-05-29 09:56:50 -05:00
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
return success;
}
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
void
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
nm_device_replace_vpn6_config (NMDevice *self, NMIP6Config *old, NMIP6Config *config)
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
vpn: fix ifindex of parent IP config in apply_parent_device_config() When creating the NMIP4Config/NMIP6Config instance, we must always use the right ifindex. That is the ifindex, on which we want to apply the config. It also means, that for device-based VPNs (those with priv->ip_ifindex set, like OpenVPN), the parent's config must have the ip-ifindex of the parent device. Not of the VPN's device. One effect of this bug is that in add_ip4_vpn_gateway_route() we resolve the route to the external gateway and only accept it if it's on the parent device. But since the ifindex of the config was wrong, we would accept route on the wrong interface. https://bugzilla.gnome.org/show_bug.cgi?id=787370
2017-09-07 10:22:10 +02:00
nm_assert (!old || NM_IS_IP6_CONFIG (old));
nm_assert (!config || NM_IS_IP6_CONFIG (config));
nm_assert (!old || nm_ip6_config_get_ifindex (old) == nm_device_get_ip_ifindex (self));
nm_assert (!config || nm_ip6_config_get_ifindex (config) == nm_device_get_ip_ifindex (self));
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
if (!_replace_vpn_config_in_list (&priv->vpn6_configs, (GObject *) old, (GObject *) config))
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
return;
/* NULL to use existing configs */
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (!ip6_config_merge_and_apply (self, TRUE))
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_IP6, "failed to set VPN routes for device");
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
}
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_set_wwan_ip6_config (NMDevice *self, NMIP6Config *config)
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
if (priv->wwan_ip6_config == config)
return;
g_clear_object (&priv->wwan_ip6_config);
if (config)
priv->wwan_ip6_config = g_object_ref (config);
/* NULL to use existing configs */
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (!ip6_config_merge_and_apply (self, TRUE))
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_IP6, "failed to set WWAN IPv6 configuration");
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
}
libnm, core, cli, tui: fix the capitalization of various types GLib/Gtk have mostly settled on the convention that two-letter acronyms in type names remain all-caps (eg, "IO"), but longer acronyms become initial-caps-only (eg, "Tcp"). NM was inconsistent, with most long acronyms using initial caps only (Adsl, Cdma, Dcb, Gsm, Olpc, Vlan), but others using all caps (DHCP, PPP, PPPOE, VPN). Fix libnm and src/ to use initial-caps only for all three-or-more-letter-long acronyms (and update nmcli and nmtui for the libnm changes).
2014-06-26 13:44:36 -04:00
NMDhcp6Config *
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
nm_device_get_dhcp6_config (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
return NM_DEVICE_GET_PRIVATE (self)->dhcp6.config;
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
}
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
NMIP6Config *
nm_device_get_ip6_config (NMDevice *self)
{
dhcp: add initial DHCPv6 support (managed mode only)
2010-01-14 00:45:10 -08:00
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
Initial IPv6 support (only handles "manual" and "ignore" currently)
2009-07-29 12:12:41 -04:00
return NM_DEVICE_GET_PRIVATE (self)->ip6_config;
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
core/trivial: move code Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:04:42 +02:00
static void
dispatcher_cleanup (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
if (priv->dispatcher.call_id) {
nm_dispatcher_call_cancel (priv->dispatcher.call_id);
priv->dispatcher.call_id = 0;
priv->dispatcher.post_state = NM_DEVICE_STATE_UNKNOWN;
priv->dispatcher.post_state_reason = NM_DEVICE_STATE_REASON_NONE;
core/trivial: move code Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:04:42 +02:00
}
}
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
static void
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
dispatcher_complete_proceed_state (guint call_id, gpointer user_data)
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
g_return_if_fail (call_id == priv->dispatcher.call_id);
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
priv->dispatcher.call_id = 0;
nm_device_queue_state (self, priv->dispatcher.post_state,
priv->dispatcher.post_state_reason);
priv->dispatcher.post_state = NM_DEVICE_STATE_UNKNOWN;
priv->dispatcher.post_state_reason = NM_DEVICE_STATE_REASON_NONE;
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
static void
ip_check_pre_up (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
if (priv->dispatcher.call_id != 0) {
g_warn_if_reached ();
dispatcher_cleanup (self);
}
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
priv->dispatcher.post_state = NM_DEVICE_STATE_SECONDARIES;
priv->dispatcher.post_state_reason = NM_DEVICE_STATE_REASON_NONE;
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
if (!nm_dispatcher_call_device (NM_DISPATCHER_ACTION_PRE_UP,
self,
NULL,
dispatcher_complete_proceed_state,
self,
&priv->dispatcher.call_id)) {
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
/* Just proceed on errors */
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
dispatcher_complete_proceed_state (0, self);
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
}
}
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
static void
ip_check_gw_ping_cleanup (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
nm_clear_g_source (&priv->gw_ping.watch);
nm_clear_g_source (&priv->gw_ping.timeout);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
if (priv->gw_ping.pid) {
core: use nm_utils_kill_child_async() and nm_utils_kill_child_sync() Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-14 11:58:06 +01:00
nm_utils_kill_child_async (priv->gw_ping.pid, SIGTERM, priv->gw_ping.log_domain, "ping", 1000, NULL, NULL);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
priv->gw_ping.pid = 0;
}
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
g_clear_pointer (&priv->gw_ping.binary, g_free);
g_clear_pointer (&priv->gw_ping.address, g_free);
}
static gboolean
spawn_ping (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
devices,platform: fix build with gcc Warnings about missing initializers.
2015-07-01 16:35:52 +02:00
gs_free char *str_timeout = NULL;
gs_free char *tmp_str = NULL;
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
const char *args[] = { priv->gw_ping.binary, "-I", nm_device_get_ip_iface (self),
"-c", "1", "-w", NULL, priv->gw_ping.address, NULL };
gs_free_error GError *error = NULL;
gboolean ret;
args[6] = str_timeout = g_strdup_printf ("%u", priv->gw_ping.deadline);
tmp_str = g_strjoinv (" ", (gchar **) args);
_LOGD (priv->gw_ping.log_domain, "ping: running '%s'", tmp_str);
ret = g_spawn_async ("/",
(gchar **) args,
NULL,
G_SPAWN_DO_NOT_REAP_CHILD,
NULL,
NULL,
&priv->gw_ping.pid,
&error);
if (!ret) {
_LOGW (priv->gw_ping.log_domain, "ping: could not spawn %s: %s",
priv->gw_ping.binary, error->message);
}
return ret;
}
static gboolean
respawn_ping_cb (gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
priv->gw_ping.watch = 0;
if (spawn_ping (self)) {
priv->gw_ping.watch = g_child_watch_add (priv->gw_ping.pid,
ip_check_ping_watch_cb, self);
} else {
ip_check_gw_ping_cleanup (self);
ip_check_pre_up (self);
}
return FALSE;
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
}
static void
ip_check_ping_watch_cb (GPid pid, gint status, gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: use explict NMLogDomain enum instead of int A while ago (f4f3f4d69b6ff89b5ec7cb9b2ca3758c149f15f5) we added an enum to represent the logging domain. Use it.
2015-05-12 16:44:24 +02:00
NMLogDomain log_domain = priv->gw_ping.log_domain;
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
gboolean success = FALSE;
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
if (!priv->gw_ping.watch)
return;
priv->gw_ping.watch = 0;
priv->gw_ping.pid = 0;
if (WIFEXITED (status)) {
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
if (WEXITSTATUS (status) == 0) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (log_domain, "ping: gateway ping succeeded");
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
success = TRUE;
} else {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (log_domain, "ping: gateway ping failed with error code %d",
WEXITSTATUS (status));
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
}
} else
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (log_domain, "ping: stopped unexpectedly with status %d", status);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
if (success) {
/* We've got connectivity, proceed to pre_up */
ip_check_gw_ping_cleanup (self);
ip_check_pre_up (self);
} else {
/* If ping exited with an error it may have returned early,
* wait 1 second and restart it */
priv->gw_ping.watch = g_timeout_add_seconds (1, respawn_ping_cb, self);
}
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
}
static gboolean
ip_check_ping_timeout_cb (gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
priv->gw_ping.timeout = 0;
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (priv->gw_ping.log_domain, "ping: gateway ping timed out");
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
ip_check_gw_ping_cleanup (self);
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
ip_check_pre_up (self);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
return FALSE;
}
static gboolean
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
start_ping (NMDevice *self,
core: use explict NMLogDomain enum instead of int A while ago (f4f3f4d69b6ff89b5ec7cb9b2ca3758c149f15f5) we added an enum to represent the logging domain. Use it.
2015-05-12 16:44:24 +02:00
NMLogDomain log_domain,
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
const char *binary,
const char *address,
guint timeout)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
g_return_val_if_fail (priv->gw_ping.watch == 0, FALSE);
g_return_val_if_fail (priv->gw_ping.timeout == 0, FALSE);
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
priv->gw_ping.log_domain = log_domain;
priv->gw_ping.address = g_strdup (address);
priv->gw_ping.binary = g_strdup (binary);
priv->gw_ping.deadline = timeout + 10; /* the proper termination is enforced by a timer */
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
if (spawn_ping (self)) {
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
priv->gw_ping.watch = g_child_watch_add (priv->gw_ping.pid, ip_check_ping_watch_cb, self);
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
priv->gw_ping.timeout = g_timeout_add_seconds (timeout, ip_check_ping_timeout_cb, self);
return TRUE;
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
}
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
ip_check_gw_ping_cleanup (self);
return FALSE;
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
}
static void
nm_device_start_ip_check (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMConnection *connection;
NMSettingConnection *s_con;
guint timeout = 0;
const char *ping_binary = NULL;
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
char buf[NM_UTILS_INET_ADDRSTRLEN];
core: use explict NMLogDomain enum instead of int A while ago (f4f3f4d69b6ff89b5ec7cb9b2ca3758c149f15f5) we added an enum to represent the logging domain. Use it.
2015-05-12 16:44:24 +02:00
NMLogDomain log_domain = LOGD_IP4;
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
/* Shouldn't be any active ping here, since IP_CHECK happens after the
* first IP method completes. Any subsequently completing IP method doesn't
* get checked.
*/
device: make some asserts less harsh We're terrible programmers, but we don't need anyone to notice!
2016-11-09 13:06:11 +01:00
g_return_if_fail (!priv->gw_ping.watch);
g_return_if_fail (!priv->gw_ping.timeout);
g_return_if_fail (!priv->gw_ping.pid);
g_return_if_fail (priv->ip4_state == IP_DONE || priv->ip6_state == IP_DONE);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
g_assert (connection);
s_con = nm_connection_get_setting_connection (connection);
g_assert (s_con);
timeout = nm_setting_connection_get_gateway_ping_timeout (s_con);
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
buf[0] = '\0';
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
if (timeout) {
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
const NMPObject *gw;
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (priv->ip4_config && priv->ip4_state == IP_DONE) {
gw = nm_ip4_config_best_default_route_get (priv->ip4_config);
if (gw) {
nm_utils_inet4_ntop (NMP_OBJECT_CAST_IP4_ROUTE (gw)->gateway, buf);
ping_binary = nm_utils_find_helper ("ping", "/usr/bin/ping", NULL);
log_domain = LOGD_IP4;
}
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
} else if (priv->ip6_config && priv->ip6_state == IP_DONE) {
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
gw = nm_ip6_config_best_default_route_get (priv->ip6_config);
if (gw) {
nm_utils_inet6_ntop (&NMP_OBJECT_CAST_IP6_ROUTE (gw)->gateway, buf);
ping_binary = nm_utils_find_helper ("ping6", "/usr/bin/ping6", NULL);
log_domain = LOGD_IP6;
}
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
}
}
if (buf[0])
device: restart ping process when it exits with an error When ping is launched to check the connectivity to the gateway it may return earlier than the given timeout in case of error. When this happens we need to respawn it until the timeout is reached. While at it, increase maximum timeout value to 600 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1128581
2015-07-01 13:42:41 +02:00
start_ping (self, log_domain, ping_binary, buf, timeout);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
/* If no ping was started, just advance to pre_up */
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
if (!priv->gw_ping.pid)
core: implement PRE_UP dispatcher actions
2014-05-21 12:49:23 -05:00
ip_check_pre_up (self);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
static gboolean
carrier_wait_timeout (gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
priv->carrier_wait_id = 0;
nm_device_remove_pending_action (self, NM_PENDING_ACTION_CARRIER_WAIT, FALSE);
if (!priv->carrier)
_carrier_wait_check_queued_act_request (self);
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
return G_SOURCE_REMOVE;
}
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
static gboolean
nm_device_is_up (NMDevice *self)
{
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
int ifindex;
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
ifindex = nm_device_get_ip_ifindex (self);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
return ifindex > 0 ? nm_platform_link_is_up (nm_device_get_platform (self), ifindex) : TRUE;
core: clean up NMDevice simple getters/setters Group most of the simple getters together near the top, and remove getters that have no callers (mtu, firmware-version).
2014-05-20 16:09:22 -05:00
}
2008-05-13 Dan Williams <dcbw@redhat.com> * src/nm-device-private.h src/nm-device.c - (nm_device_hw_bring_up, nm_device_hw_take_down): export * src/nm-device-802-11-wireless.c - (nm_device_802_11_wireless_set_enabled): take devices up and down as appropriate for the rfkill state git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3666 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-14 01:55:49 +00:00
gboolean
core: rename nm_device_hw_* to nm_device_* Now that we only have one set of is_up/bring_up/take_down functions lets rename the _hw_ variants.
2013-06-13 15:13:58 -05:00
nm_device_bring_up (NMDevice *self, gboolean block, gboolean *no_firmware)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
gboolean device_is_up = FALSE;
device: re-read carrier-detect capability after bringing device up https://bugzilla.gnome.org/show_bug.cgi?id=766179
2016-05-09 18:32:29 +02:00
NMDeviceCapabilities capabilities;
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
int ifindex;
2007-03-12 Dan Williams <dcbw@redhat.com> Get rid of 2 second poll of sysfs 'carrier' file for wired devices. Useless for non-carrier-detect capable devices, and useless for carrier-detect devices since we get notifications from netlink about carrier status anyway. * src/nm-device-802-3-ethernet.c - remove 'link_source_id' member from private data - (probe_link): remove and collapse into real_update_link() - (nm_device_802_3_periodic_update): remove - (real_is_up): check for sup_iface rather than link_source_id - (real_bring_up): return gboolean for success/fail; require that sup_iface be valid for device bringup to succeed - (real_bring_down): zero out link signal ids * src/nm-device.c - (nm_device_activate_stage2_device_config): fail activation if device bringup fails - (real_act_stage4_get_ip4_config): fail activation if device bringup fails - (nm_device_bring_up): return success/fail * src/nm-device.h - bring_up now returns success/fail * src/nm-device-802-11-wireless.c - (real_bring_up): return success from bringup git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2464 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-03-12 04:49:29 +00:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: drop NMDeviceWifi:bring_up() implementation Instead of letting the sub-class check the "enabled" state, let it be handled by nm_device_bring_up(). Note that nm_device_get_enabled() only has two implementations: NMDeviceModem:bring_up() and NMDeviceWifi:bring_up().
2016-09-12 12:32:27 +02:00
NM_SET_OUT (no_firmware, FALSE);
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
if (!nm_device_get_enabled (self)) {
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGD (LOGD_PLATFORM, "bringing up device ignored due to disabled");
device: drop NMDeviceWifi:bring_up() implementation Instead of letting the sub-class check the "enabled" state, let it be handled by nm_device_bring_up(). Note that nm_device_get_enabled() only has two implementations: NMDeviceModem:bring_up() and NMDeviceWifi:bring_up().
2016-09-12 12:32:27 +02:00
return FALSE;
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
}
device: drop NMDeviceWifi:bring_up() implementation Instead of letting the sub-class check the "enabled" state, let it be handled by nm_device_bring_up(). Note that nm_device_get_enabled() only has two implementations: NMDeviceModem:bring_up() and NMDeviceWifi:bring_up().
2016-09-12 12:32:27 +02:00
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
ifindex = nm_device_get_ip_ifindex (self);
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGD (LOGD_PLATFORM, "bringing up device %d", ifindex);
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
if (ifindex <= 0) {
/* assume success. */
} else {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_set_up (nm_device_get_platform (self), ifindex, no_firmware))
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
return FALSE;
}
device: don't check_carrier() during bring_up() Don't check the carrier state inside the virtual function bring_up().
2016-05-09 18:30:06 +02:00
/* Store carrier immediately. */
device: cleanup nm_device_set_carrier_from_platform() nm_device_set_carrier_from_platform() is only called from two places. - both check for NM_DEVICE_CAP_CARRIER_DETECT, so move that check inside the function. - drop the logging in realize_start_setup(). nm_device_set_carrier() already does logging. - always set the fake carrier in nm_device_set_carrier_from_platform(). For the fake carrer, we anyway expect it to be already TRUE in most case, so usually this should have no effect. Also emit a property changed signal. That is necessary to refresh the D-Bus property.
2017-05-15 11:35:41 +02:00
nm_device_set_carrier_from_platform (self);
device: don't check_carrier() during bring_up() Don't check the carrier state inside the virtual function bring_up().
2016-05-09 18:30:06 +02:00
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
device_is_up = nm_device_is_up (self);
if (block && !device_is_up) {
gint64 wait_until = nm_utils_get_monotonic_timestamp_us () + 10000 /* microseconds */;
do {
g_usleep (200);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_refresh (nm_device_get_platform (self), ifindex))
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
return FALSE;
device_is_up = nm_device_is_up (self);
} while (!device_is_up && nm_utils_get_monotonic_timestamp_us () < wait_until);
}
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
if (!device_is_up) {
if (block)
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGW (LOGD_PLATFORM, "device not up after timeout!");
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
else
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGD (LOGD_PLATFORM, "device not up immediately");
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
return FALSE;
}
device: re-read carrier-detect capability after bringing device up https://bugzilla.gnome.org/show_bug.cgi?id=766179
2016-05-09 18:32:29 +02:00
/* some ethernet devices fail to report capabilities unless the device
* is up. Re-read the capabilities. */
capabilities = 0;
if (NM_DEVICE_GET_CLASS (self)->get_generic_capabilities)
capabilities |= NM_DEVICE_GET_CLASS (self)->get_generic_capabilities (self);
_add_capabilities (self, capabilities);
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
/* Devices that support carrier detect must be IFF_UP to report carrier
* changes; so after setting the device IFF_UP we must suppress startup
* complete (via a pending action) until either the carrier turns on, or
* a timeout is reached.
*/
device: expose nm_device_has_capability() function
2015-04-17 15:19:48 +02:00
if (nm_device_has_capability (self, NM_DEVICE_CAP_CARRIER_DETECT)) {
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
gint64 now_ms, until_ms;
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
/* we start a grace period of 5 seconds during which we will schedule
* a pending action whenever we have no carrier.
*
* If during that time carrier goes away, we declare the interface
* as not ready. */
nm_clear_g_source (&priv->carrier_wait_id);
if (!priv->carrier)
nm_device_add_pending_action (self, NM_PENDING_ACTION_CARRIER_WAIT, FALSE);
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
now_ms = nm_utils_get_monotonic_timestamp_ms ();
until_ms = NM_MAX (now_ms + CARRIER_WAIT_TIME_MS, priv->carrier_wait_until_ms);
priv->carrier_wait_id = g_timeout_add (until_ms - now_ms, carrier_wait_timeout, self);
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
}
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
/* Can only get HW address of some devices when they are up */
core: reorganize hw-address properties Now that NMDevice reads the hwaddr directly from netlink, it's silly to have every device subtype maintain its own hw-address property (using data that it gets from the NMDevice base class). Remove all the device-specific hw-address properties, and add one to NMDevice instead. (Because of the way nm-properties-changed-signal works, this has no effect on the D-Bus API.) Subclasses now call nm_device_get_hw_address() in places where they used to just refer to priv->hw_addr (and to simplify this, we now allow passing NULL for the out length parameter, since the subclasses almost always know what the length will be already). Also reorganize/simplify a few other methods to take advantage of the fact that NMDevice is now keeping track of the hw-address directly. https://bugzilla.gnome.org/show_bug.cgi?id=699391
2013-05-01 09:28:16 -04:00
nm_device_update_hw_address (self);
2007-03-02 Tambet Ingo <tambet@ximian.com> * libnm-glib/nm-device-802-11-wireless.c: Cache networks (bssids) list. We get signalled when it changes. * libnm-glib/nm-client.c: Cache NMState and device list, we get signalled when it changes. * libnm-glib/nm-device.c: Cache the device state property. * libnm-glib/nm-access-point.c: Cache the strength property. * src/nm-device-802-11-wireless.c: Fix wireless device scanning scheduler. The new algorithm is to start from SCAN_INTERVAL_MIN (currently defined as 0) and add a SCAN_INTERVAL_STEP (currently 20 seconds) with each successful scan until SCAN_INTERVAL_MAX (currently 120 seconds) is reached. Do not scan while the device is down, activating, or activated (in case of A/B/G cards). Remove some old dead ifdef'ed out code that used to configure wireless devices, it's all done through supplicant now. * src/supplicant-manager/nm-supplicant-interface.c: Fix the reference counting issues with pending calls which caused leaks and crashes when interface was removed (now that the interface actually gets removed). * src/nm-call-store.c: Make a copy of data before running a foreach with user callback on it - The most common usage pattern is to cancel (and thus remove) all pending calls with foreach which would modify the hash table we're iterating over. * src/nm-manager.c: When a device is added, make sure it is "up". When it's removed or disabled due to disabling wireless or networking, bring it down. * include/NetworkManager.h: Add new device state NM_DEVICE_STATE_DOWN. * src/nm-device-802-11-wireless.c: * src/nm-device-802-3-ethernet.c: * src/nm-device.c: - Remove "init" virtual function, all gobjects have a place for that already (constructor). - Replace "start" virtual function with "bring_up", devices can be brought up and down more than just on startup now. - Add "is_up" virtual function. - Implement one way to bring a device down instead of previous 4 different ways, each of witch did something different. * src/NetworkManagerUtils.c (nm_dev_sock_open): This doesn't need an NMDevice, all it needs is the device interface. Get rid of NMData.dev_list (3 members to go). Get rif of NMData in a lot of places. * gnome/libnm_glib/libnm_glib.c: Make it compile again. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2395 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-03-02 09:30:48 +00:00
core: move NMDevice private functions to nm-device-private.h Move stuff that's not "public" API of NMDevice to the private header that's only used by subclasses.
2011-11-17 22:39:34 -06:00
_update_ip4_address (self);
device: reconfigure IP addressing after bringing up device For changing the hardware address, we must bring the device down. When doing that, IP addressing is lost and it must be re-configured after bringing the device up again. We already do something similar in device_link_changed(), but that might not be sufficient, because device_link_changed() is run on an idle handler, thus, while changing the hardware address it has no chance to run (or notice that the device was shortly down). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-05-29 17:54:36 +02:00
/* when the link comes up, we must restore IP configuration if necessary. */
if (priv->ip4_state == IP_DONE) {
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
if (!ip4_config_merge_and_apply (self, TRUE))
device: reconfigure IP addressing after bringing up device For changing the hardware address, we must bring the device down. When doing that, IP addressing is lost and it must be re-configured after bringing the device up again. We already do something similar in device_link_changed(), but that might not be sufficient, because device_link_changed() is run on an idle handler, thus, while changing the hardware address it has no chance to run (or notice that the device was shortly down). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-05-29 17:54:36 +02:00
_LOGW (LOGD_IP4, "failed applying IP4 config after bringing link up");
}
if (priv->ip6_state == IP_DONE) {
device: remove out-reason argument from device's set-ip-config The out-reason is only set to NM_DEVICE_STATE_REASON_CONFIG_FAILED. And there is only one caller who cares about the reason. If we one day decide to return a more distinguished error reasons, we can revert this patch. Until then, drop the code.
2017-02-22 20:20:22 +01:00
if (!ip6_config_merge_and_apply (self, TRUE))
device: reconfigure IP addressing after bringing up device For changing the hardware address, we must bring the device down. When doing that, IP addressing is lost and it must be re-configured after bringing the device up again. We already do something similar in device_link_changed(), but that might not be sufficient, because device_link_changed() is run on an idle handler, thus, while changing the hardware address it has no chance to run (or notice that the device was shortly down). https://bugzilla.redhat.com/show_bug.cgi?id=1309899
2016-05-29 17:54:36 +02:00
_LOGW (LOGD_IP6, "failed applying IP6 config after bringing link up");
}
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
return TRUE;
}
2008-05-13 Dan Williams <dcbw@redhat.com> * src/nm-device-private.h src/nm-device.c - (nm_device_hw_bring_up, nm_device_hw_take_down): export * src/nm-device-802-11-wireless.c - (nm_device_802_11_wireless_set_enabled): take devices up and down as appropriate for the rfkill state git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3666 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-14 01:55:49 +00:00
void
core: rename nm_device_hw_* to nm_device_* Now that we only have one set of is_up/bring_up/take_down functions lets rename the _hw_ variants.
2013-06-13 15:13:58 -05:00
nm_device_take_down (NMDevice *self, gboolean block)
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
{
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
int ifindex;
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
gboolean device_is_up;
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
g_return_if_fail (NM_IS_DEVICE (self));
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
ifindex = nm_device_get_ip_ifindex (self);
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGD (LOGD_PLATFORM, "taking down device %d", ifindex);
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
if (ifindex <= 0) {
/* devices without ifindex are always up. */
return;
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
}
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_set_down (nm_device_get_platform (self), ifindex))
device: drop virtual methods for bring_up(), take_down() and is_up() They have no more implementations in derived classes.
2016-09-12 12:01:56 +02:00
return;
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
device_is_up = nm_device_is_up (self);
if (block && device_is_up) {
gint64 wait_until = nm_utils_get_monotonic_timestamp_us () + 10000 /* microseconds */;
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
do {
g_usleep (200);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_refresh (nm_device_get_platform (self), ifindex))
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
return;
device_is_up = nm_device_is_up (self);
} while (device_is_up && nm_utils_get_monotonic_timestamp_us () < wait_until);
}
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
if (device_is_up) {
if (block)
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGW (LOGD_PLATFORM, "device not down after timeout!");
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
else
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGD (LOGD_PLATFORM, "device not down immediately");
core: fix waiting for bringing up/taking down device This fixes a regression introduced in 5074898591ae99f79b0cc4872c3c7cf018abee82. The while loop did only refetch the cached value (because the glib main loop was blocked and only the cached device flags were checked). Also, instead on relying of g_usleep(), wait until a maximum time of waiting is expired. The duration of g_usleep() might not be very accurate. Also, do no longer check the cached device state before setting the device flag. The cache might be out of date, so we just set the flag. https://bugzilla.gnome.org/show_bug.cgi?id=724363 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-11 14:00:20 +01:00
}
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
void
nm_device_set_firmware_missing (NMDevice *self, gboolean new_missing)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
NMDevicePrivate *priv;
2008-04-17 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (nm_device_state_changed): do deactivation and and promotion to unavailable here, so that the device gets cleaned up before the manager runs and starts emitting signals; do the FAILED->DISCONNECTED transition from an idle handler rather than immediately to guard against recursion - (nm_device_deactivate_quickly, nm_device_dispose): stop the FAILED->DISCONNECTED handler if it's scheduled git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3573 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-17 23:04:34 +00:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_return_if_fail (NM_IS_DEVICE (self));
core: base infrastructure for connection assumption Figure out what connections can be assumed when a device is added, and on shutdown don't blow away connections that can be assumed on NM restart.
2009-08-03 17:15:03 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv = NM_DEVICE_GET_PRIVATE (self);
if (priv->firmware_missing != new_missing) {
priv->firmware_missing = new_missing;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_FIRMWARE_MISSING);
core: base infrastructure for connection assumption Figure out what connections can be assumed when a device is added, and on shutdown don't blow away connections that can be assumed on NM restart.
2009-08-03 17:15:03 -04:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: base infrastructure for connection assumption Figure out what connections can be assumed when a device is added, and on shutdown don't blow away connections that can be assumed on NM restart.
2009-08-03 17:15:03 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
gboolean
nm_device_get_firmware_missing (NMDevice *self)
{
return NM_DEVICE_GET_PRIVATE (self)->firmware_missing;
}
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static NMIP4Config *
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
find_ip4_lease_config (NMDevice *self,
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
NMConnection *connection,
NMIP4Config *ext_ip4_config)
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
const char *ip_iface = nm_device_get_ip_iface (self);
core: pass ifindex as parameter to nm_ip4_config_new()
2015-02-20 16:31:10 -06:00
int ip_ifindex = nm_device_get_ip_ifindex (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
GSList *leases, *liter;
NMIP4Config *found = NULL;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_return_val_if_fail (NM_IS_IP4_CONFIG (ext_ip4_config), NULL);
g_return_val_if_fail (NM_IS_CONNECTION (connection), NULL);
core: simplify DHCP setup and cleanup nm_device_set_use_dhcp() and nm_device_get_use_dhcp() were somewhat confusing and don't really reflect the new DHCP architecture with NMDHCPClient. Now that timeout and state signals are specific to the NMDHCPClient it doesn't make sense to check for DHCP use in the callbacks for those signals since they'll never get called if DHCP isn't in use. We might as well just keep the DHCP manager around and check whether a DHCP client instance exists when we need to figure out whether DHCP is in use.
2010-01-13 17:59:54 -08:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
leases = nm_dhcp_manager_get_lease_ip_configs (nm_dhcp_manager_get (),
core: pass NMDedupMultiIndex instance to NMIP4Config and other NMIP4Config, NMIP6Config, and NMPlatform shall share one NMDedupMultiIndex instance. For that, pass an NMDedupMultiIndex instance to NMPlatform and NMNetns. NMNetns than passes it on to NMDevice, NMDhcpClient, NMIP4Config and NMIP6Config. So currently NMNetns is the access point to the shared NMDedupMultiIndex instance, and it gets it from it's NMPlatform instance. The NMDedupMultiIndex instance is really a singleton, we don't want multiple instances of it. However, for testing, instead of adding a singleton instance, pass the instance explicitly around.
2017-06-12 08:16:47 +02:00
nm_device_get_multi_index (self),
core/dhcp: use addr-family parameter for instead of boolean In many cases we want to treat IPv4 and IPv6 generically. That looks nicer if we distingish by an @addr_family integer, instead of a boolean. Replace the @is_ipv6 boolean with an @addr_family paramter. The @is_ipv6 boolean is inconsistent with other places where we use @is_ipv4 to indicate the opposite. Eventually, we should use @addr_family everywhere. Also, at the call site it's not immediately clear what TRUE/FALSE means, here AF_INET/AF_INET6 is better.
2017-09-11 11:30:48 +02:00
AF_INET,
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
ip_iface,
core: pass ifindex as parameter to nm_ip4_config_new()
2015-02-20 16:31:10 -06:00
ip_ifindex,
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
nm_connection_get_uuid (connection),
core: use ipv4.route-table setting for other IPv4 routes Including device-routes, default-route, DHCPv4, IPv4LL.
2017-09-28 14:40:12 +02:00
nm_device_get_route_table (self, AF_INET, TRUE),
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
nm_device_get_route_metric (self, AF_INET));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
for (liter = leases; liter && !found; liter = liter->next) {
NMIP4Config *lease_config = liter->data;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
const NMPlatformIP4Address *address = nm_ip4_config_get_first_address (lease_config);
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
const NMPObject *gw1, *gw2;
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_assert (address);
if (!nm_ip4_config_address_exists (ext_ip4_config, address))
continue;
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
gw1 = nm_ip4_config_best_default_route_get (lease_config);
if (!gw1)
continue;
gw2 = nm_ip4_config_best_default_route_get (ext_ip4_config);
if (!gw2)
continue;
if (NMP_OBJECT_CAST_IP4_ROUTE (gw1)->gateway != NMP_OBJECT_CAST_IP4_ROUTE (gw2)->gateway)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
continue;
found = g_object_ref (lease_config);
}
2008-07-11 Dan Williams <dcbw@redhat.com> Modify the NMDevice::state-changed signal to include the previous state and reason. Enables the applet to provide more information why device activation failed. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3819 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-07-11 10:28:53 +00:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_slist_free_full (leases, g_object_unref);
return found;
}
core: remove bring_up, take_down, is_up device class methods These turn out to be pretty useless, since their functions are already covered by each device's state-changed handler or can be done in other places like deactivate(). https://bugzilla.gnome.org/show_bug.cgi?id=702190
2013-06-12 10:48:03 -05:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
capture_lease_config (NMDevice *self,
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
NMIP4Config *ext_ip4_config,
NMIP4Config **out_ip4_config,
NMIP6Config *ext_ip6_config,
NMIP6Config **out_ip6_config)
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
NMSettingsConnection *const*connections;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
guint i;
gboolean dhcp_used = FALSE;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
NMDedupMultiIter ipconf_iter;
devices: enable/disable kernel IPv6 autoconf at the appropriate times Set accept_ra and use_tempaddr to "0" when managing a device (and restore them to their original values after unmanaging it) to ensure that calling nm_device_bring_up() on a managed device won't ever cause kernel IPv6 autoconf to happen. Remove some other redundant accept_ra setting. Fix up the deconfigure case of dispose() to clear the device's IP6 config as well as its IP4 config. https://bugzilla.gnome.org/show_bug.cgi?id=700414
2013-10-24 13:55:06 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Ensure at least one address on the device has a non-infinite lifetime,
* otherwise DHCP cannot possibly be active on the device right now.
*/
if (ext_ip4_config && out_ip4_config) {
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
const NMPlatformIP4Address *addr;
devices: enable/disable kernel IPv6 autoconf at the appropriate times Set accept_ra and use_tempaddr to "0" when managing a device (and restore them to their original values after unmanaging it) to ensure that calling nm_device_bring_up() on a managed device won't ever cause kernel IPv6 autoconf to happen. Remove some other redundant accept_ra setting. Fix up the deconfigure case of dispose() to clear the device's IP6 config as well as its IP4 config. https://bugzilla.gnome.org/show_bug.cgi?id=700414
2013-10-24 13:55:06 -04:00
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
nm_ip_config_iter_ip4_address_for_each (&ipconf_iter, ext_ip4_config, &addr) {
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
if (addr->lifetime != NM_PLATFORM_LIFETIME_PERMANENT) {
dhcp_used = TRUE;
break;
}
}
} else if (ext_ip6_config && out_ip6_config) {
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
const NMPlatformIP6Address *addr;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
nm_ip_config_iter_ip6_address_for_each (&ipconf_iter, ext_ip6_config, &addr) {
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
if (addr->lifetime != NM_PLATFORM_LIFETIME_PERMANENT) {
dhcp_used = TRUE;
break;
}
}
} else {
g_return_if_fail ( (ext_ip6_config && out_ip6_config)
|| (ext_ip4_config && out_ip4_config));
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
if (!dhcp_used)
return;
core: track VPN routes on the master device, not the VPN When a VPN wanted to add some routes (like the host route for the VPN gateway) it would add them itself and listen for parent device events and re-add them if necessary. That's pretty fragile, plus the platform blows away routes that aren't part of the IP config that's getting applied. So we might as well just have the VPN connection tell the parent what the routes are, and have the parent device handle updating the routing. The routes are through the parent device anyway, and so are "owned" by the parent too.
2013-08-01 10:59:42 -05:00
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
connections = nm_settings_get_connections (priv->settings, NULL);
for (i = 0; connections[i]; i++) {
NMConnection *candidate = (NMConnection *) connections[i];
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
const char *method;
core: add support for IPv6 Privacy Extensions for SLAAC (RFC4941) (bgo #633233)
2012-02-21 15:44:19 +01:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
if (!nm_device_check_connection_compatible (self, candidate))
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
continue;
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* IPv4 leases */
method = nm_utils_get_ip_config_method (candidate, NM_TYPE_SETTING_IP4_CONFIG);
if (out_ip4_config && strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_AUTO) == 0) {
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
*out_ip4_config = find_ip4_lease_config (self, candidate, ext_ip4_config);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
if (*out_ip4_config)
return;
}
core: move carrier handling to NMDevice Move carrier handling for most device types into NMDevice. Based on an earlier patch by Pavel Šimerda.
2013-05-07 10:23:44 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* IPv6 leases */
method = nm_utils_get_ip_config_method (candidate, NM_TYPE_SETTING_IP6_CONFIG);
if (out_ip6_config && strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_AUTO) == 0) {
/* FIXME: implement find_ip6_lease_config() */
}
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
static gboolean
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
update_ext_ip_config (NMDevice *self, int addr_family, gboolean initial, gboolean intersect_configs)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
int ifindex;
gboolean capture_resolv_conf;
device: minor cleanup replacing g_slist_for_each() by iteration Iterating a list is so easy, it's easier to just do it by hand, then splitting the functionality accross multiple lines.
2017-05-26 22:46:57 +02:00
GSList *iter;
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
nm_assert_addr_family (addr_family);
device: postpone updates of IP configuration when a commit is pending When a new dynamic configuration is received, it is stored in a member of private structure (e.g. @dhcp6_ip6_config) and a commit is scheduled. Before the commit is executed, an update_ipx_config() could be called and it would change the configuration before it is committed. This race condition causes failures in assigning the addresses received through DHCPv6 when the internal client is used (but potentially other clients and methods are affected). To fix it, postpone updates of IP configurations when a commit is already pending.
2016-04-28 22:48:39 +02:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
ifindex = nm_device_get_ip_ifindex (self);
if (!ifindex)
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
return FALSE;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
dns: merge the dns "mode" and "rc-manager" Already previously, the mode and rc-manager were intertwined in a complicated way: - dns=none effectively disables rc-manager. - if resolv.conf was immutable, it would disable the rc-manager by setting "resolv_conf_mode=NM_DNS_MANAGER_RESOLV_CONF_UNMANAGED". - resolv_conf_mode was anyway a redundant piece of information to rc_manager. Now there are only two relevant settings: priv->plugin and priv->rc_manager. And they can be set independently from each other. Before that was not possible. For example, you could not set a dns plugin with rc-manager=unmanaged (the only way to achive that was via an immutable resolv.conf or by having rc-manager=symlink and let resolv.conf link somewhere else.
2016-04-21 18:09:17 +02:00
capture_resolv_conf = initial
&& nm_dns_manager_get_resolv_conf_explicit (nm_dns_manager_get ());
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
if (addr_family == AF_INET) {
g_clear_object (&priv->ext_ip4_config);
priv->ext_ip4_config = nm_ip4_config_capture (nm_device_get_multi_index (self),
nm_device_get_platform (self),
ifindex,
capture_resolv_conf);
if (priv->ext_ip4_config) {
if (initial) {
g_clear_object (&priv->dev_ip4_config);
capture_lease_config (self, priv->ext_ip4_config, &priv->dev_ip4_config, NULL, NULL);
}
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
if (intersect_configs) {
/* This function was called upon external changes. Remove the configuration
* (addresses,routes) that is no longer present externally from the internal
* config. This way, we don't re-add addresses that were manually removed
* by the user. */
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (priv->con_ip4_config) {
nm_ip4_config_intersect (priv->con_ip4_config, priv->ext_ip4_config,
default_route_metric_penalty_get (self, AF_INET));
}
if (priv->dev_ip4_config) {
nm_ip4_config_intersect (priv->dev_ip4_config, priv->ext_ip4_config,
default_route_metric_penalty_get (self, AF_INET));
}
if (priv->wwan_ip4_config) {
nm_ip4_config_intersect (priv->wwan_ip4_config, priv->ext_ip4_config,
default_route_metric_penalty_get (self, AF_INET));
}
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
for (iter = priv->vpn4_configs; iter; iter = iter->next)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip4_config_intersect (iter->data, priv->ext_ip4_config, 0);
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
}
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
/* Remove parts from ext_ip4_config to only contain the information that
* was configured externally -- we already have the same configuration from
* internal origins. */
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (priv->con_ip4_config) {
nm_ip4_config_subtract (priv->ext_ip4_config, priv->con_ip4_config,
default_route_metric_penalty_get (self, AF_INET));
}
if (priv->dev_ip4_config) {
nm_ip4_config_subtract (priv->ext_ip4_config, priv->dev_ip4_config,
default_route_metric_penalty_get (self, AF_INET));
}
if (priv->wwan_ip4_config) {
nm_ip4_config_subtract (priv->ext_ip4_config, priv->wwan_ip4_config,
default_route_metric_penalty_get (self, AF_INET));
}
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
for (iter = priv->vpn4_configs; iter; iter = iter->next)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip4_config_subtract (priv->ext_ip4_config, iter->data, 0);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
} else {
nm_assert (addr_family == AF_INET6);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
g_clear_object (&priv->ext_ip6_config);
g_clear_object (&priv->ext_ip6_config_captured);
priv->ext_ip6_config_captured = nm_ip6_config_capture (nm_device_get_multi_index (self),
nm_device_get_platform (self),
ifindex,
capture_resolv_conf,
NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN);
if (priv->ext_ip6_config_captured) {
priv->ext_ip6_config = nm_ip6_config_new_cloned (priv->ext_ip6_config_captured);
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
if (intersect_configs) {
/* This function was called upon external changes. Remove the configuration
* (addresses,routes) that is no longer present externally from the internal
* config. This way, we don't re-add addresses that were manually removed
* by the user. */
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (priv->con_ip6_config) {
nm_ip6_config_intersect (priv->con_ip6_config, priv->ext_ip6_config,
default_route_metric_penalty_get (self, AF_INET6));
}
if (priv->ac_ip6_config) {
nm_ip6_config_intersect (priv->ac_ip6_config, priv->ext_ip6_config,
default_route_metric_penalty_get (self, AF_INET6));
}
if (priv->dhcp6.ip6_config) {
nm_ip6_config_intersect (priv->dhcp6.ip6_config, priv->ext_ip6_config,
default_route_metric_penalty_get (self, AF_INET6));
}
if (priv->wwan_ip6_config) {
nm_ip6_config_intersect (priv->wwan_ip6_config, priv->ext_ip6_config,
default_route_metric_penalty_get (self, AF_INET6));
}
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
for (iter = priv->vpn6_configs; iter; iter = iter->next)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip6_config_intersect (iter->data, priv->ext_ip6_config, 0);
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
}
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
/* Remove parts from ext_ip6_config to only contain the information that
* was configured externally -- we already have the same configuration from
* internal origins. */
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
if (priv->con_ip6_config) {
nm_ip6_config_subtract (priv->ext_ip6_config, priv->con_ip6_config,
default_route_metric_penalty_get (self, AF_INET6));
}
if (priv->ac_ip6_config) {
nm_ip6_config_subtract (priv->ext_ip6_config, priv->ac_ip6_config,
default_route_metric_penalty_get (self, AF_INET6));
}
if (priv->dhcp6.ip6_config) {
nm_ip6_config_subtract (priv->ext_ip6_config, priv->dhcp6.ip6_config,
default_route_metric_penalty_get (self, AF_INET6));
}
if (priv->wwan_ip6_config) {
nm_ip6_config_subtract (priv->ext_ip6_config, priv->wwan_ip6_config,
default_route_metric_penalty_get (self, AF_INET6));
}
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
for (iter = priv->vpn6_configs; iter; iter = iter->next)
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
nm_ip6_config_subtract (priv->ext_ip6_config, iter->data, 0);
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
}
core: delay startup complete until carrier is found or timeout (rh #1034921) (rh #1030583) Carrier state is only valid if the network interface is IFF_UP, because drivers are not required to do carrier detection if the device is not up. Thus, if NM is the first process to set the interface IFF_UP, there may be a short delay while the driver performs carrier detection. NetworkManager must suppress "startup complete" during this delay to ensure that the carrier state is known before making startup property decisions. Previously, when NetworkManager set the interface IFF_UP, the interface would not have a carrier for a few seconds until the driver's carrier detection was done. Since the interface had no carrier, NetworkManager could not begin connection activation on the interface, and the interface would not suppress the "startup complete" transition. Thus, NetworkManager would declare that startup was complete prematurely and anything depending on startup network connectivity would fail as no interfaces were active. https://bugzilla.redhat.com/show_bug.cgi?id=1034921 https://bugzilla.redhat.com/show_bug.cgi?id=1030583
2013-12-09 16:32:36 -06:00
}
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
return TRUE;
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
}
static void
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
update_ip_config (NMDevice *self, int addr_family, gboolean initial)
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: cleanup handling addr_family in NMDevice - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
2017-10-02 13:55:27 +02:00
nm_assert_addr_family (addr_family);
2008-05-29 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (dnsmasq_state_changed_cb): new function; fail the connection if something happens to dnsmasq - (nm_device_new_ip4_shared_config): new function; create a new ip4-config for shared connections. Shared connections always use a fixed static IP address. - (real_act_stage4_get_ip4_config): handle shared connections; fix autoip connections by actually using the returned ip4-config and not leaking it - (nm_device_activate_stage5_ip_config_commit): start dnsmasq for shared connections - (nm_device_deactivate_quickly, nm_device_dispose): terminate dnsmasq if its active git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3711 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-05-29 20:58:52 +00:00
device: do full update_ext_ip_config() during merge-and-apply Since commit a21b8882cc9defc43248afc94bf59ca0f84f0d27 ("device: update external configuration before commit"), we correctly re-sync the external IP configuration before a merge, in case we notice that there were some changes in platform. Go a step further, and do the full update_ext_ip_config(). We should have one way how to capture the external config, including intersect and subtract. Otherwise, we end up with an @ext_ip4_config, which is different from how it looks usually.
2017-09-22 12:11:32 +02:00
if (update_ext_ip_config (self, addr_family, initial, TRUE)) {
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
if (addr_family == AF_INET) {
if (priv->ext_ip4_config)
device: factor out config argument to ip4_config_merge_and_apply()
2017-09-28 14:22:07 +02:00
ip4_config_merge_and_apply (self, FALSE);
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
} else {
if (priv->ext_ip6_config_captured)
ip6_config_merge_and_apply (self, FALSE);
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: add IP configuration for unmanaged devices Use NMPlatform to read the IP address/route configuration of unmanaged devices, and export that via D-Bus like we do with NM-generated IP configs.
2013-04-04 10:20:24 -04:00
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
if ( addr_family == AF_INET6
&& priv->linklocal6_timeout_id
device: add ext_ip6_config_captured to remember the last-read platform configuration ext_ip6_config gets modified to only contain items that are configured externally, not by internal choice.
2016-01-30 21:37:22 +01:00
&& priv->ext_ip6_config_captured
device: move have_ip6_address() to nm_ip6_config_get_address_first_nontentative()
2016-01-30 22:28:23 +01:00
&& nm_ip6_config_get_address_first_nontentative (priv->ext_ip6_config_captured, TRUE)) {
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* linklocal6 is ready now, do the state transition... we are also
* invoked as g_idle_add, so no problems with reentrance doing it now.
*/
linklocal6_complete (self);
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_capture_initial_config (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
update_ip_config (self, AF_INET, TRUE);
update_ip_config (self, AF_INET6, TRUE);
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
}
static gboolean
queued_ip4_config_change (gpointer user_data)
{
device: add assertions for queued_ip4_config_change() and queued_ip6_config_change()
2016-05-05 11:05:07 +02:00
NMDevice *self = user_data;
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), G_SOURCE_REMOVE);
priv = NM_DEVICE_GET_PRIVATE (self);
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
nm_assert (!priv->queued_ip4_config_pending);
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
/* Wait for any queued state changes */
if (priv->queued_state.id)
return TRUE;
priv->queued_ip4_config_id = 0;
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
/* If a commit is scheduled, this function would potentially interfere with
* it changing IP configurations before they are applied. Postpone the
* update in such case.
*/
if (activation_source_is_scheduled (self,
activate_stage5_ip4_config_result,
AF_INET)) {
priv->queued_ip4_config_pending = FALSE;
priv->queued_ip4_config_id = g_idle_add (queued_ip4_config_change, self);
_LOGT (LOGD_DEVICE, "IP4 update was postponed");
} else
update_ip_config (self, AF_INET, FALSE);
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
device: consider external devices as unmanaged until they have an IP address
2016-03-21 15:30:07 +01:00
set_unmanaged_external_down (self, TRUE);
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
if (!nm_device_sys_iface_state_is_external_or_assume (self)) {
priv->v4_has_shadowed_routes = _v4_has_shadowed_routes_detect (self);;
ip4_rp_filter_update (self);
}
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
return FALSE;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
static gboolean
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
queued_ip6_config_change (gpointer user_data)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
device: add assertions for queued_ip4_config_change() and queued_ip6_config_change()
2016-05-05 11:05:07 +02:00
NMDevice *self = user_data;
NMDevicePrivate *priv;
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
GSList *iter;
gboolean need_ipv6ll = FALSE;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: add assertions for queued_ip4_config_change() and queued_ip6_config_change()
2016-05-05 11:05:07 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), G_SOURCE_REMOVE);
priv = NM_DEVICE_GET_PRIVATE (self);
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
nm_assert (!priv->queued_ip4_config_pending);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Wait for any queued state changes */
if (priv->queued_state.id)
return TRUE;
firewall: add firewall manager src/firewall-manager tracks whether firewall is on the bus or not. In nm-device.c at stage5 (ip-config-commit) before we actually apply the IP configuration to the interface, we send the IP interface name and zone to firewall and asynchronously wait for a D-Bus reply. Then after we get the reply (or if the firewall isn't running) we proceed with applying the IP configuration to the interface.
2011-10-07 15:58:08 +02:00
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
priv->queued_ip6_config_id = 0;
device: refactor update-ip-config for device Refactor the code. There should be no changes in behavior at all. The point is, to be able to reuse update_ext_ip_config() in the next commit. And also, I think it's an antipattern to have mirroring functions like ip4_xyz() and ip6_xyz(). Instead, there should be one function, with extra addr_family argument. That way, it'much clearer where two implementations differ and where they are identical. Basically, it moves the differentiation per the address family down the call stack, closer to the place where the behavior is actually different.
2017-09-22 10:56:38 +02:00
/* If a commit is scheduled, this function would potentially interfere with
* it changing IP configurations before they are applied. Postpone the
* update in such case.
*/
if (activation_source_is_scheduled (self,
activate_stage5_ip6_config_commit,
AF_INET6)) {
priv->queued_ip6_config_pending = FALSE;
priv->queued_ip6_config_id = g_idle_add (queued_ip6_config_change, self);
_LOGT (LOGD_DEVICE, "IP6 update was postponed");
} else
update_ip_config (self, AF_INET6, FALSE);
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
device: allow ipv6ll address to be set for disconnected devices Commit f85941ee9101 ("device: don't try to generate ipv6ll address for disconnected devices") disabled the generation of IPv6 link-local addresses for disconnected devices to fix a crash. However that broke the following: $ ip a f dev eth0 $ systemctl start NetworkManager $ nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet disconnected eth0 $ ip a a dev eth0 2001::42/64 $ ip a show eth0 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:52:00:61:32:81 brd ff:ff:ff:ff:ff:ff inet6 2001::42/64 scope global valid_lft forever preferred_lft forever (no link-local address) Instead, enable the generation of a link-local address even if the device is disconnected and fix nm_device_get_ip_iface_identifier() to not require a connection if @ignore_token is set. Fixes: f85941ee91017079f30afac80e7b39c44cb04c81
2016-07-07 16:29:25 +02:00
if (priv->state < NM_DEVICE_STATE_DEACTIVATING
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
&& nm_platform_link_get (nm_device_get_platform (self), priv->ifindex)) {
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
/* Handle DAD failures */
device: don't try to re-add addresses that vanish on device disconnection They are not DAD failures. Also, we must not try adding link-local address when disconnecting.
2015-11-12 12:41:26 +01:00
for (iter = priv->dad6_failed_addrs; iter; iter = g_slist_next (iter)) {
NMPlatformIP6Address *addr = iter->data;
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
core/trivial: rename "source" field of addresses and routes The "source" field of NMPlatformIPRoute (now "rt_source") maps to the protocol field of the route. The source of NMPlatformIPAddress (now "addr_source") has no direct equivalent in the kernel. As their use is different, they should have different names. Also, the name "source" is used all over the place. Hence give the fields a more distinct name.
2016-04-11 13:09:52 +02:00
if (addr->addr_source >= NM_IP_CONFIG_SOURCE_USER)
device: don't try to re-add addresses that vanish on device disconnection They are not DAD failures. Also, we must not try adding link-local address when disconnecting.
2015-11-12 12:41:26 +01:00
continue;
_LOGI (LOGD_IP6, "ipv6: duplicate address check failed for the %s address",
nm_platform_ip6_address_to_string (addr, NULL, 0));
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
device: don't try to re-add addresses that vanish on device disconnection They are not DAD failures. Also, we must not try adding link-local address when disconnecting.
2015-11-12 12:41:26 +01:00
if (IN6_IS_ADDR_LINKLOCAL (&addr->address))
need_ipv6ll = TRUE;
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
else if (priv->ndisc)
nm_ndisc_dad_failed (priv->ndisc, &addr->address);
device: don't try to re-add addresses that vanish on device disconnection They are not DAD failures. Also, we must not try adding link-local address when disconnecting.
2015-11-12 12:41:26 +01:00
}
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
device: don't try to re-add addresses that vanish on device disconnection They are not DAD failures. Also, we must not try adding link-local address when disconnecting.
2015-11-12 12:41:26 +01:00
/* If no IPv6 link-local address exists but other addresses do then we
* must add the LL address to remain conformant with RFC 3513 chapter 2.1
* ("Addressing Model"): "All interfaces are required to have at least
* one link-local unicast address".
*/
if (priv->ip6_config && nm_ip6_config_get_num_addresses (priv->ip6_config))
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
need_ipv6ll = TRUE;
device: don't try to re-add addresses that vanish on device disconnection They are not DAD failures. Also, we must not try adding link-local address when disconnecting.
2015-11-12 12:41:26 +01:00
if (need_ipv6ll)
check_and_add_ipv6ll_addr (self);
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
}
device: don't try to re-add addresses that vanish on device disconnection They are not DAD failures. Also, we must not try adding link-local address when disconnecting.
2015-11-12 12:41:26 +01:00
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
g_slist_free_full (priv->dad6_failed_addrs, g_free);
device: fix a dad6_failed_addrs use-after-free
2015-11-05 16:39:19 +01:00
priv->dad6_failed_addrs = NULL;
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
/* Check if DAD is still pending */
if ( priv->ip6_state == IP_CONF
&& priv->dad6_ip6_config
&& priv->ext_ip6_config_captured) {
if (!nm_ip6_config_has_any_dad_pending (priv->ext_ip6_config_captured,
priv->dad6_ip6_config)) {
_LOGD (LOGD_DEVICE | LOGD_IP6, "IPv6 DAD terminated");
g_clear_object (&priv->dad6_ip6_config);
device: log changes to ip4_state and ip6_state
2016-08-29 14:27:46 +02:00
_set_ip_state (self, AF_INET6, IP_DONE);
device: rework state transition after IP configuration Unify the two check_ip_done() and check_ip_failed() functions into a single one to have all the state transition logic in the same place. This also fixes a regression introduced by commit 553717bb1c9 ("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled"). After that commit the device immediately proceeded to IP_CHECK when there was a disabled/ignore method. Now we wait for the termination of the other method, like it used to be. Fixes: 553717bb1c9ed31be0fab85bc37f6823dc8ab480 https://bugzilla.gnome.org/show_bug.cgi?id=771579
2016-09-19 10:51:56 +02:00
check_ip_state (self, FALSE);
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
if (priv->rt6_temporary_not_available)
nm_device_activate_schedule_ip6_config_result (self);
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
}
}
device: consider external devices as unmanaged until they have an IP address
2016-03-21 15:30:07 +01:00
set_unmanaged_external_down (self, TRUE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
return FALSE;
}
core: convert pending actions from a counter to a GArray This lets us do two things: 1) ensure that pending actions are unique and not doubly added/removed 2) we can (eventually) print out the pending action list for debugging However, since we cannot have two pending actions with the same name at the same time, we need to change the queued device state actions to include the state name. But that makes debugging even more descriptive so it's a bonus.
2013-12-09 12:55:04 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
device_ipx_changed (NMPlatform *platform,
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
int obj_type_i,
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
int ifindex,
gpointer platform_object,
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
int change_type_i,
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
NMDevice *self)
{
core: don't use generated glib enum for platform types
2016-10-22 13:08:36 +02:00
const NMPObjectType obj_type = obj_type_i;
const NMPlatformSignalChangeType change_type = change_type_i;
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
NMDevicePrivate *priv;
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
NMPlatformIP6Address *addr;
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
if (nm_device_get_ip_ifindex (self) != ifindex)
return;
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
switch (obj_type) {
case NMP_OBJECT_TYPE_IP4_ADDRESS:
case NMP_OBJECT_TYPE_IP4_ROUTE:
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
if (nm_device_get_unmanaged_flags (self, NM_UNMANAGED_PLATFORM_INIT)) {
priv->queued_ip4_config_pending = TRUE;
nm_assert_se (!nm_clear_g_source (&priv->queued_ip4_config_id));
} else if (!priv->queued_ip4_config_id) {
priv->queued_ip4_config_pending = FALSE;
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
priv->queued_ip4_config_id = g_idle_add (queued_ip4_config_change, self);
_LOGD (LOGD_DEVICE, "queued IP4 config change");
}
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
break;
case NMP_OBJECT_TYPE_IP6_ADDRESS:
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
addr = platform_object;
nm-device: don't try to re-add LL address if the devices is torn down Fixes: 9f92bb1f630d20674b83ad96a4d3fea299d9d12f
2015-11-25 11:07:33 +01:00
if ( priv->state > NM_DEVICE_STATE_DISCONNECTED
&& priv->state < NM_DEVICE_STATE_DEACTIVATING
platform/trivial: rename NMPlatformIP6Address's "flags" field to "n_ifa_flags" There are far too many "flags". Rename the "flags" to "n_ifa_flags" which reminds to "ifa_flags" in 'struct ifaddrmsg', but with a distinctive "n_" prefix.
2016-02-29 16:23:16 +01:00
&& ( (change_type == NM_PLATFORM_SIGNAL_CHANGED && addr->n_ifa_flags & IFA_F_DADFAILED)
|| (change_type == NM_PLATFORM_SIGNAL_REMOVED && addr->n_ifa_flags & IFA_F_TENTATIVE))) {
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
priv->dad6_failed_addrs = g_slist_append (priv->dad6_failed_addrs,
g_memdup (addr, sizeof (NMPlatformIP6Address)));
}
all: cleanup switch fall-through comments for -Wimplicit-fallthrough warning The -Wimplicit-fallthrough=3 warning is quite flexible of accepting a fall-through warning. Some comments were missing or not detected correctly. Thereby, also change all other comments to follow the exact same pattern.
2017-02-06 14:42:47 +01:00
/* fall through */
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
case NMP_OBJECT_TYPE_IP6_ROUTE:
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
if (nm_device_get_unmanaged_flags (self, NM_UNMANAGED_PLATFORM_INIT)) {
priv->queued_ip6_config_pending = TRUE;
nm_assert_se (!nm_clear_g_source (&priv->queued_ip6_config_id));
} else if (!priv->queued_ip6_config_id) {
priv->queued_ip6_config_pending = FALSE;
device: split IP config changes signal handling to IPv4 and IPv6 So that we don't process IPv4 changes for IPv6 and vice versa.
2015-06-24 08:59:36 +00:00
priv->queued_ip6_config_id = g_idle_add (queued_ip6_config_change, self);
_LOGD (LOGD_DEVICE, "queued IP6 config change");
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
}
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
break;
default:
g_return_if_reached ();
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
}
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
/*****************************************************************************/
NM_UTILS_FLAGS2STR_DEFINE (nm_unmanaged_flags2str, NMUnmanagedFlags,
NM_UTILS_FLAGS2STR (NM_UNMANAGED_SLEEPING, "sleeping"),
NM_UTILS_FLAGS2STR (NM_UNMANAGED_QUITTING, "quitting"),
NM_UTILS_FLAGS2STR (NM_UNMANAGED_PARENT, "parent"),
NM_UTILS_FLAGS2STR (NM_UNMANAGED_LOOPBACK, "loopback"),
NM_UTILS_FLAGS2STR (NM_UNMANAGED_PLATFORM_INIT, "platform-init"),
NM_UTILS_FLAGS2STR (NM_UNMANAGED_USER_EXPLICIT, "user-explicit"),
NM_UTILS_FLAGS2STR (NM_UNMANAGED_BY_DEFAULT, "by-default"),
device: rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS The NM_UNMANAGED_USER_SETTINGS flags are determined by the settings plugins. That is, either: - keyfile's "unmanaged-devices" configuration option - ifcfg-rh's "NM_CONTROLLED" option - ifnet's "managed" option Rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS to reflect that it this is user configuration determined by the settings plugin.
2016-02-22 14:45:45 +01:00
NM_UTILS_FLAGS2STR (NM_UNMANAGED_USER_SETTINGS, "user-settings"),
device: add configuration option to mark devices as unmanaged We already have various ways to mark a device as unmanaged. 1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus at runtime. 2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and keyfile.unmanaged-devices in NetworkManager.conf. 3) at runtime, via D-Bus. This is persisted in the run state file and persists restarts (but not reboot). This adds another way via NetworkManager.conf file. Note that the existing keyfile.unmanaged-devices (above 2) is also a configuration optin in NetworkManager.conf. However it has various downsides: - it cannot be overwritten at runtime (see commit c210134bd58ea40ee3458aff27ab41958e1f48b4). - you can only explicitly mark a device as unmanaged. That means, you cannot use it to manage a device which is unmanaged due to a udev rule. - the name "keyfile.*" sounds like it's only relevant for the keyfile settings plugin. Nowadays the keyfile plugin is always loaded, so the option applies to NetworkManager in general. https://github.com/NetworkManager/NetworkManager/pull/29
2017-09-26 16:28:49 +02:00
NM_UTILS_FLAGS2STR (NM_UNMANAGED_USER_CONF, "user-conf"),
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
NM_UTILS_FLAGS2STR (NM_UNMANAGED_USER_UDEV, "user-udev"),
NM_UTILS_FLAGS2STR (NM_UNMANAGED_EXTERNAL_DOWN, "external-down"),
NM_UTILS_FLAGS2STR (NM_UNMANAGED_IS_SLAVE, "is-slave"),
);
static const char *
_unmanaged_flags2str (NMUnmanagedFlags flags, NMUnmanagedFlags mask, char *buf, gsize len)
{
char buf2[512];
char *b;
char *tmp, *tmp2;
gsize l;
nm_utils_to_string_buffer_init (&buf, &len);
if (!len)
return buf;
b = buf;
mask |= flags;
nm_unmanaged_flags2str (flags, b, len);
l = strlen (b);
b += l;
len -= l;
nm_unmanaged_flags2str (mask & ~flags, buf2, sizeof (buf2));
if (buf2[0]) {
gboolean add_separator = l > 0;
tmp = buf2;
while (TRUE) {
if (add_separator)
nm_utils_strbuf_append_c (&b, &len, ',');
add_separator = TRUE;
tmp2 = strchr (tmp, ',');
if (tmp2)
tmp2[0] = '\0';
nm_utils_strbuf_append_c (&b, &len, '!');
nm_utils_strbuf_append_str (&b, &len, tmp);
if (!tmp2)
break;
tmp = &tmp2[1];
}
}
return buf;
}
static gboolean
_get_managed_by_flags(NMUnmanagedFlags flags, NMUnmanagedFlags mask, gboolean for_user_request)
{
/* Evaluate the managed state based on the unmanaged flags.
*
* Some flags are authoritative, meaning they always cause
* the device to be unmanaged (e.g. @NM_UNMANAGED_PLATFORM_INIT).
*
device: clearify behavior of NM_UNMANAGED_USER_SETTINGS in comment
2016-06-22 14:04:25 +02:00
* OTOH, some flags can be overwritten. For example NM_UNMANAGED_USER_UDEV
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* is ignored once NM_UNMANAGED_USER_EXPLICIT is set. The idea is that
* the flag from the configuration has no effect once the user explicitly
* touches the unmanaged flags. */
if (for_user_request) {
/* @for_user_request can make the result only ~more~ managed.
* If the flags already indicate a managed state for a non-user-request,
* then it is also managed for an explict user-request.
*
* Effectively, this check is redundant, as the code below already
* already ensures that. Still, express this invariant explictly here. */
if (_get_managed_by_flags (flags, mask, FALSE))
return TRUE;
/* A for-user-request, is effectively the same as pretending
* that user-dbus flag is cleared. */
mask |= NM_UNMANAGED_USER_EXPLICIT;
flags &= ~NM_UNMANAGED_USER_EXPLICIT;
}
device: rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS The NM_UNMANAGED_USER_SETTINGS flags are determined by the settings plugins. That is, either: - keyfile's "unmanaged-devices" configuration option - ifcfg-rh's "NM_CONTROLLED" option - ifnet's "managed" option Rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS to reflect that it this is user configuration determined by the settings plugin.
2016-02-22 14:45:45 +01:00
if ( NM_FLAGS_ANY (mask, NM_UNMANAGED_USER_SETTINGS)
&& !NM_FLAGS_ANY (flags, NM_UNMANAGED_USER_SETTINGS)) {
/* NM_UNMANAGED_USER_SETTINGS can only explicitly unmanage a device. It cannot
* *manage* it. Having NM_UNMANAGED_USER_SETTINGS explicitly not set, is the
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* same as having it not set at all. */
device: rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS The NM_UNMANAGED_USER_SETTINGS flags are determined by the settings plugins. That is, either: - keyfile's "unmanaged-devices" configuration option - ifcfg-rh's "NM_CONTROLLED" option - ifnet's "managed" option Rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS to reflect that it this is user configuration determined by the settings plugin.
2016-02-22 14:45:45 +01:00
mask &= ~NM_UNMANAGED_USER_SETTINGS;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
}
device: revert overruling NM_UNMANAGED_USER_SETTINGS decision Since commit 87a3df2e572ed47b5f76f6d1cad63ce622296e21, the unmanaged flag NM_UNMANAGED_USER_SETTINGS could be overwritten via an explict user decision (NM_UNMANAGED_USER_EXPLICIT). It makes sense to allow user configuration from file to be changable by an explict user action via D-Bus at runtime. However, it also changes behavior for devices that are currently explicitly managed. Previously, a reload of the NM_UNMANAGED_USER_SETTINGS would immediately unmanaged the device: - for keyfile: send SIGHUP to reload NetworkManager.conf - for ifcfg-rh: `nmcli connection [re]load` So this change in behavior could negatively affect users who rely on being able to configure "NM_CONTROLLED=no" and expect to unmanaged the device immediately. Thus revert the change. Note that NM_UNMANAGED_USER_SETTINGS is anyway ugly and should be deprecated: - for keyfile, why having the option "keyfile.unmanaged-devices" instead of a generic options? - for ifcfg-rh, why put per-device configuration in a per-connection file? The preferred way is to configure NM_UNMANAGED_USER_UDEV via "ENV{NM_UNMANAGED}". Maybe we should also add a new configuration scheme via NetworkManager.conf. https://bugzilla.gnome.org/show_bug.cgi?id=762331
2016-02-22 15:53:06 +01:00
if (NM_FLAGS_ANY (mask, NM_UNMANAGED_USER_UDEV)) {
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
/* configuration from udev or nm-config overwrites the by-default flag
device: add configuration option to mark devices as unmanaged We already have various ways to mark a device as unmanaged. 1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus at runtime. 2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and keyfile.unmanaged-devices in NetworkManager.conf. 3) at runtime, via D-Bus. This is persisted in the run state file and persists restarts (but not reboot). This adds another way via NetworkManager.conf file. Note that the existing keyfile.unmanaged-devices (above 2) is also a configuration optin in NetworkManager.conf. However it has various downsides: - it cannot be overwritten at runtime (see commit c210134bd58ea40ee3458aff27ab41958e1f48b4). - you can only explicitly mark a device as unmanaged. That means, you cannot use it to manage a device which is unmanaged due to a udev rule. - the name "keyfile.*" sounds like it's only relevant for the keyfile settings plugin. Nowadays the keyfile plugin is always loaded, so the option applies to NetworkManager in general. https://github.com/NetworkManager/NetworkManager/pull/29
2017-09-26 16:28:49 +02:00
* which is based on the device type.
* configuration from udev overwrites external-down */
flags &= ~( NM_UNMANAGED_BY_DEFAULT
| NM_UNMANAGED_EXTERNAL_DOWN);
}
device: let managed by user-udev overwrite external-down An externally configured software device is considered external-down until it is IF_UP and has IP configuration. When the user explicitly manages the device via UDEV rule, that decision should overrule external-down.
2016-04-08 11:36:13 +02:00
device: add configuration option to mark devices as unmanaged We already have various ways to mark a device as unmanaged. 1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus at runtime. 2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and keyfile.unmanaged-devices in NetworkManager.conf. 3) at runtime, via D-Bus. This is persisted in the run state file and persists restarts (but not reboot). This adds another way via NetworkManager.conf file. Note that the existing keyfile.unmanaged-devices (above 2) is also a configuration optin in NetworkManager.conf. However it has various downsides: - it cannot be overwritten at runtime (see commit c210134bd58ea40ee3458aff27ab41958e1f48b4). - you can only explicitly mark a device as unmanaged. That means, you cannot use it to manage a device which is unmanaged due to a udev rule. - the name "keyfile.*" sounds like it's only relevant for the keyfile settings plugin. Nowadays the keyfile plugin is always loaded, so the option applies to NetworkManager in general. https://github.com/NetworkManager/NetworkManager/pull/29
2017-09-26 16:28:49 +02:00
if (NM_FLAGS_ANY (mask, NM_UNMANAGED_USER_CONF)) {
/* configuration from NetworkManager.conf overwrites the by-default flag
* which is based on the device type.
* It also overwrites the udev configuration and external-down */
flags &= ~( NM_UNMANAGED_BY_DEFAULT
device: fix handling NM_UNMANAGED_USER_CONF in _get_managed_by_flags() Found by clang warning: src/devices/nm-device.c:11370:14: error: use of logical '||' with constant operand [-Werror,-Wconstant-logical-operand] || NM_UNMANAGED_USER_UDEV ^ ~~~~~~~~~~~~~~~~~~~~~~ Fixes: 5778bc6a34f2291d68247695119f2170bc3bf8b3
2017-10-05 14:45:25 +02:00
| NM_UNMANAGED_USER_UDEV
| NM_UNMANAGED_EXTERNAL_DOWN);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
}
if ( NM_FLAGS_HAS (mask, NM_UNMANAGED_IS_SLAVE)
&& !NM_FLAGS_HAS (flags, NM_UNMANAGED_IS_SLAVE)) {
/* for an enslaved device, by-default doesn't matter */
flags &= ~NM_UNMANAGED_BY_DEFAULT;
}
if (NM_FLAGS_HAS (mask, NM_UNMANAGED_USER_EXPLICIT)) {
/* if the device is managed by user-decision, certain other flags
* are ignored. */
flags &= ~( NM_UNMANAGED_BY_DEFAULT
| NM_UNMANAGED_USER_UDEV
device: add configuration option to mark devices as unmanaged We already have various ways to mark a device as unmanaged. 1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus at runtime. 2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and keyfile.unmanaged-devices in NetworkManager.conf. 3) at runtime, via D-Bus. This is persisted in the run state file and persists restarts (but not reboot). This adds another way via NetworkManager.conf file. Note that the existing keyfile.unmanaged-devices (above 2) is also a configuration optin in NetworkManager.conf. However it has various downsides: - it cannot be overwritten at runtime (see commit c210134bd58ea40ee3458aff27ab41958e1f48b4). - you can only explicitly mark a device as unmanaged. That means, you cannot use it to manage a device which is unmanaged due to a udev rule. - the name "keyfile.*" sounds like it's only relevant for the keyfile settings plugin. Nowadays the keyfile plugin is always loaded, so the option applies to NetworkManager in general. https://github.com/NetworkManager/NetworkManager/pull/29
2017-09-26 16:28:49 +02:00
| NM_UNMANAGED_USER_CONF
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
| NM_UNMANAGED_EXTERNAL_DOWN);
}
return flags == NM_UNMANAGED_NONE;
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/**
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* nm_device_get_managed:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the #NMDevice
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* @for_user_request: whether to check the flags for an explict user-request
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* Whether the device is unmanaged according to the unmanaged flags.
*
* Returns: %TRUE if the device is unmanaged because of the flags.
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*/
gboolean
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_get_managed (NMDevice *self, gboolean for_user_request)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
NMDevicePrivate *priv;
core: reorganize hw-address properties Now that NMDevice reads the hwaddr directly from netlink, it's silly to have every device subtype maintain its own hw-address property (using data that it gets from the NMDevice base class). Remove all the device-specific hw-address properties, and add one to NMDevice instead. (Because of the way nm-properties-changed-signal works, this has no effect on the D-Bus API.) Subclasses now call nm_device_get_hw_address() in places where they used to just refer to priv->hw_addr (and to simplify this, we now allow passing NULL for the out length parameter, since the subclasses almost always know what the length will be already). Also reorganize/simplify a few other methods to take advantage of the fact that NMDevice is now keeping track of the hw-address directly. https://bugzilla.gnome.org/show_bug.cgi?id=699391
2013-05-01 09:28:16 -04:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
if (!nm_device_is_real (self)) {
/* a unrealized device is always considered unmanaged. */
return FALSE;
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
return _get_managed_by_flags (priv->unmanaged_flags, priv->unmanaged_mask, for_user_request);
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
}
device: add nm_device_get_unmanaged_mask()
2016-03-23 09:39:22 +01:00
/**
* nm_device_get_unmanaged_mask:
* @self: the #NMDevice
* @flag: the unmanaged flags to check.
*
* Return the unmanaged flags mask set on this device.
*
* Returns: the flags of the device ( & @flag)
*/
NMUnmanagedFlags
nm_device_get_unmanaged_mask (NMDevice *self, NMUnmanagedFlags flag)
{
g_return_val_if_fail (NM_IS_DEVICE (self), NM_UNMANAGED_NONE);
g_return_val_if_fail (flag != NM_UNMANAGED_NONE, NM_UNMANAGED_NONE);
return NM_DEVICE_GET_PRIVATE (self)->unmanaged_mask & flag;
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/**
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* nm_device_get_unmanaged_flags:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the #NMDevice
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* @flag: the unmanaged flags to check.
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* Return the unmanaged flags of the device.
*
* Returns: the flags of the device ( & @flag)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*/
device: return the unmanaged flags from nm_device_get_unmanaged_flags()
2015-11-05 02:41:42 +01:00
NMUnmanagedFlags
core/trivial: rename functions
2015-11-05 02:32:53 +01:00
nm_device_get_unmanaged_flags (NMDevice *self, NMUnmanagedFlags flag)
core: handle new device states The device states aren't used yet, but handle them anyway.
2011-03-17 13:39:31 -05:00
{
device: add nm_device_get_unmanaged_mask()
2016-03-23 09:39:22 +01:00
g_return_val_if_fail (NM_IS_DEVICE (self), NM_UNMANAGED_NONE);
g_return_val_if_fail (flag != NM_UNMANAGED_NONE, NM_UNMANAGED_NONE);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
device: return the unmanaged flags from nm_device_get_unmanaged_flags()
2015-11-05 02:41:42 +01:00
return NM_DEVICE_GET_PRIVATE (self)->unmanaged_flags & flag;
core: handle new device states The device states aren't used yet, but handle them anyway.
2011-03-17 13:39:31 -05:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/**
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* _set_unmanaged_flags:
* @self: the #NMDevice instance
* @flags: which #NMUnmanagedFlags to set.
* @set_op: whether to set/clear/forget the flags. You can also pass
* boolean values %TRUE and %FALSE, which mean %NM_UNMAN_FLAG_OP_SET_UNMANAGED
* and %NM_UNMAN_FLAG_OP_SET_MANAGED, respectively.
* @allow_state_transition: if %FALSE, setting flags never triggers a device
* state change. If %TRUE, the device can change state, if it is real and
* switches from managed to unmanaged (or vice versa).
device: add nm_device_set_unmanaged_by_flags_queue() Useful for setting a device as unmanaged during another state change.
2016-05-05 11:05:04 +02:00
* @now: whether the state change should be immediate or delayed
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* @reason: the device state reason passed to nm_device_state_changed() if
* the device becomes managed/unmanaged. This is only relevant if the
* device switches state and if @allow_state_transition is %TRUE.
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
* Set the unmanaged flags of the device.
**/
device: add debug log for setting unmanged flags Only set priv->unmanaged_flags in one place and log any changes. It is not trivial to understand from the logfile why a device is unmanged.
2015-06-29 18:06:12 +02:00
static void
_set_unmanaged_flags (NMDevice *self,
NMUnmanagedFlags flags,
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
NMUnmanFlagOp set_op,
gboolean allow_state_transition,
device: add nm_device_set_unmanaged_by_flags_queue() Useful for setting a device as unmanaged during another state change.
2016-05-05 11:05:04 +02:00
gboolean now,
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
NMDeviceStateReason reason)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
NMDevicePrivate *priv;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
gboolean was_managed, transition_state;
NMUnmanagedFlags old_flags, old_mask;
device: add nm_device_set_unmanaged_by_flags_queue() Useful for setting a device as unmanaged during another state change.
2016-05-05 11:05:04 +02:00
NMDeviceState new_state;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
const char *operation = NULL;
char str1[512];
char str2[512];
device: delay startup complete until device is initialized in platform Udev may be slow at startup and it may take a while until the device is visible in udev. Before that, there are no pending actions yet because the device is still in unmanaged state. Hack nm_device_has_pending_action() to indicate a pending action when the platform link is not yet initialized. We don't bother using nm_device_add_pending_action() to schedule a proper pending-action. It is simpler this way, also we precisely log about the state of NM_UNMANAGED_PLATFORM_INIT flag. The pending actions are implemented in their way mostly for logging purpose to understand what blocks a device. For NM_UNMANAGED_PLATFORM_INIT we have sufficient logging so no need for the overhead and effort. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-13 18:45:36 +01:00
gboolean do_notify_has_pending_actions = FALSE;
gboolean had_pending_actions = FALSE;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
g_return_if_fail (flags);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
if (!priv->real)
allow_state_transition = FALSE;
was_managed = allow_state_transition && nm_device_get_managed (self, FALSE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
if ( NM_FLAGS_HAS (priv->unmanaged_flags, NM_UNMANAGED_PLATFORM_INIT)
&& NM_FLAGS_HAS (flags, NM_UNMANAGED_PLATFORM_INIT)
&& NM_IN_SET (set_op, NM_UNMAN_FLAG_OP_SET_MANAGED)) {
/* we are clearing the platform-init flags. This triggers additional actions. */
if (!NM_FLAGS_HAS (flags, NM_UNMANAGED_USER_SETTINGS)) {
gboolean unmanaged;
unmanaged = nm_device_spec_match_list (self,
nm_settings_get_unmanaged_specs (NM_DEVICE_GET_PRIVATE (self)->settings));
nm_device_set_unmanaged_flags (self,
NM_UNMANAGED_USER_SETTINGS,
!!unmanaged);
}
device: don't evaluate IP config changes until device is initialized The unmanaged flags PLATFORM_INIT indicates whether UDEV is done initializing the device. We should not handle IP config changes before that pointer. This avoids codepaths that require the permanent MAC address of the device. We should not freeze the permanent MAC address before UDEV initialized the device, for two reasons: - getting the permanent MAC address using ethtool is racy as UDEV might still rename the interface. - freezing a fake permanent MAC address should only happen after UDEV is done configuring the MAC address of software devices. #0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817 #1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0) at src/devices/nm-device.c:12227 #2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237 #3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294 #4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461 #5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277 #6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169 #7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234 #8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142 #9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161 #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at src/devices/nm-device.c:4787 #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532 #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651 #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154 #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769 #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034 #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
2016-10-26 13:43:49 +02:00
if (priv->queued_ip4_config_pending) {
priv->queued_ip4_config_pending = FALSE;
nm_assert_se (!nm_clear_g_source (&priv->queued_ip4_config_id));
priv->queued_ip4_config_id = g_idle_add (queued_ip4_config_change, self);
}
if (priv->queued_ip6_config_pending) {
priv->queued_ip6_config_pending = FALSE;
nm_assert_se (!nm_clear_g_source (&priv->queued_ip6_config_id));
priv->queued_ip6_config_id = g_idle_add (queued_ip6_config_change, self);
}
device: delay startup complete until device is initialized in platform Udev may be slow at startup and it may take a while until the device is visible in udev. Before that, there are no pending actions yet because the device is still in unmanaged state. Hack nm_device_has_pending_action() to indicate a pending action when the platform link is not yet initialized. We don't bother using nm_device_add_pending_action() to schedule a proper pending-action. It is simpler this way, also we precisely log about the state of NM_UNMANAGED_PLATFORM_INIT flag. The pending actions are implemented in their way mostly for logging purpose to understand what blocks a device. For NM_UNMANAGED_PLATFORM_INIT we have sufficient logging so no need for the overhead and effort. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-13 18:45:36 +01:00
if (!priv->pending_actions) {
do_notify_has_pending_actions = TRUE;
had_pending_actions = nm_device_has_pending_action (self);
}
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
}
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
old_flags = priv->unmanaged_flags;
old_mask = priv->unmanaged_mask;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
switch (set_op) {
case NM_UNMAN_FLAG_OP_FORGET:
priv->unmanaged_mask &= ~flags;
priv->unmanaged_flags &= ~flags;
operation = "forget";
break;
case NM_UNMAN_FLAG_OP_SET_UNMANAGED:
priv->unmanaged_mask |= flags;
priv->unmanaged_flags |= flags;
operation = "set-unmanaged";
break;
case NM_UNMAN_FLAG_OP_SET_MANAGED:
priv->unmanaged_mask |= flags;
priv->unmanaged_flags &= ~flags;
operation = "set-managed";
break;
default:
g_return_if_reached ();
}
if ( old_flags == priv->unmanaged_flags
&& old_mask == priv->unmanaged_mask)
return;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
transition_state = allow_state_transition
&& was_managed != nm_device_get_managed (self, FALSE)
&& ( was_managed
|| ( !was_managed
&& nm_device_get_state (self) == NM_DEVICE_STATE_UNMANAGED));
device: remove macro for logging in _set_unmanaged_flags() The macro is used exactly once. It's simpler to just write the logging statement down as is.
2017-03-15 10:28:48 +01:00
_LOGD (LOGD_DEVICE, "unmanaged: flags set to [%s%s0x%0x/0x%x/%s%s], %s [%s=0x%0x]%s%s%s)",
_unmanaged_flags2str (priv->unmanaged_flags, priv->unmanaged_mask, str1, sizeof (str1)), \
(priv->unmanaged_flags | priv->unmanaged_mask) ? "=" : "", \
(guint) priv->unmanaged_flags, \
(guint) priv->unmanaged_mask, \
(_get_managed_by_flags (priv->unmanaged_flags, priv->unmanaged_mask, FALSE) \
? "managed" \
: (_get_managed_by_flags (priv->unmanaged_flags, priv->unmanaged_mask, TRUE) \
? "manageable" \
: "unmanaged")),
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
priv->real ? "" : "/unrealized",
operation,
nm_unmanaged_flags2str (flags, str2, sizeof (str2)),
flags,
NM_PRINT_FMT_QUOTED (allow_state_transition,
", reason ",
reason_to_string (reason),
transition_state ? ", transition-state" : "",
""));
device: delay startup complete until device is initialized in platform Udev may be slow at startup and it may take a while until the device is visible in udev. Before that, there are no pending actions yet because the device is still in unmanaged state. Hack nm_device_has_pending_action() to indicate a pending action when the platform link is not yet initialized. We don't bother using nm_device_add_pending_action() to schedule a proper pending-action. It is simpler this way, also we precisely log about the state of NM_UNMANAGED_PLATFORM_INIT flag. The pending actions are implemented in their way mostly for logging purpose to understand what blocks a device. For NM_UNMANAGED_PLATFORM_INIT we have sufficient logging so no need for the overhead and effort. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-13 18:45:36 +01:00
if ( do_notify_has_pending_actions
&& had_pending_actions != nm_device_has_pending_action (self))
_notify (self, PROP_HAS_PENDING_ACTION);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
if (transition_state) {
device: add nm_device_set_unmanaged_by_flags_queue() Useful for setting a device as unmanaged during another state change.
2016-05-05 11:05:04 +02:00
new_state = was_managed ? NM_DEVICE_STATE_UNMANAGED : NM_DEVICE_STATE_UNAVAILABLE;
if (now)
nm_device_state_changed (self, new_state, reason);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
else
device: add nm_device_set_unmanaged_by_flags_queue() Useful for setting a device as unmanaged during another state change.
2016-05-05 11:05:04 +02:00
nm_device_queue_state (self, new_state, reason);
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
}
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
/**
* @self: the #NMDevice instance
* @flags: which #NMUnmanagedFlags to set.
* @set_op: whether to set/clear/forget the flags. You can also pass
* boolean values %TRUE and %FALSE, which mean %NM_UNMAN_FLAG_OP_SET_UNMANAGED
* and %NM_UNMAN_FLAG_OP_SET_MANAGED, respectively.
*
* Set the unmanaged flags of the device (does not trigger a state change).
**/
void
nm_device_set_unmanaged_flags (NMDevice *self,
NMUnmanagedFlags flags,
NMUnmanFlagOp set_op)
{
device: add nm_device_set_unmanaged_by_flags_queue() Useful for setting a device as unmanaged during another state change.
2016-05-05 11:05:04 +02:00
_set_unmanaged_flags (self, flags, set_op, FALSE, FALSE, NM_DEVICE_STATE_REASON_NONE);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
}
/**
* nm_device_set_unmanaged_by_flags:
* @self: the #NMDevice instance
* @flags: which #NMUnmanagedFlags to set.
* @set_op: whether to set/clear/forget the flags. You can also pass
* boolean values %TRUE and %FALSE, which mean %NM_UNMAN_FLAG_OP_SET_UNMANAGED
* and %NM_UNMAN_FLAG_OP_SET_MANAGED, respectively.
* @reason: the device state reason passed to nm_device_state_changed() if
* the device becomes managed/unmanaged.
*
* Set the unmanaged flags of the device and possibly trigger a state change.
**/
void
nm_device_set_unmanaged_by_flags (NMDevice *self,
NMUnmanagedFlags flags,
NMUnmanFlagOp set_op,
NMDeviceStateReason reason)
{
device: add nm_device_set_unmanaged_by_flags_queue() Useful for setting a device as unmanaged during another state change.
2016-05-05 11:05:04 +02:00
_set_unmanaged_flags (self, flags, set_op, TRUE, TRUE, reason);
}
void
nm_device_set_unmanaged_by_flags_queue (NMDevice *self,
NMUnmanagedFlags flags,
NMUnmanFlagOp set_op,
NMDeviceStateReason reason)
{
_set_unmanaged_flags (self, flags, set_op, TRUE, FALSE, reason);
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
}
device: refactor setting unmanaged based on device-spec
2015-09-15 23:53:46 +02:00
void
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
nm_device_set_unmanaged_by_user_settings (NMDevice *self)
device: refactor setting unmanaged based on device-spec
2015-09-15 23:53:46 +02:00
{
gboolean unmanaged;
g_return_if_fail (NM_IS_DEVICE (self));
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
if (nm_device_get_unmanaged_flags (self, NM_UNMANAGED_PLATFORM_INIT)) {
/* the device is already unmanaged due to platform-init.
*
* We want to delay evaluating the device spec, because it will freeze
* the permanent MAC address. That should not be done, before the platform
* link is fully initialized (via UDEV).
*
* Note that when clearing NM_UNMANAGED_PLATFORM_INIT, we will re-evaluate
* whether the device is unmanaged by user-settings. */
return;
}
device: refactor setting unmanaged based on device-spec
2015-09-15 23:53:46 +02:00
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
unmanaged = nm_device_spec_match_list (self,
nm_settings_get_unmanaged_specs (NM_DEVICE_GET_PRIVATE (self)->settings));
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
device/trivial: rename nm_device_set_unmanaged_flags()
2016-01-13 12:03:47 +01:00
nm_device_set_unmanaged_by_flags (self,
device: rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS The NM_UNMANAGED_USER_SETTINGS flags are determined by the settings plugins. That is, either: - keyfile's "unmanaged-devices" configuration option - ifcfg-rh's "NM_CONTROLLED" option - ifnet's "managed" option Rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS to reflect that it this is user configuration determined by the settings plugin.
2016-02-22 14:45:45 +01:00
NM_UNMANAGED_USER_SETTINGS,
device: delay evaluating unmanaged-by-user-settings flags until link initialized Before the link is initialized, that is before UDEV completed initializing the device, we should not evaluate the user-settings unmanaged flags. The reason is, that evaluating it likely involves looking at the permanent MAC address, which might use the wrong fake MAC address (before UDEV set the right one). Also, it might use the wrong ifname to lookup the permanent MAC address via ethtool.
2016-10-25 15:27:57 +02:00
!!unmanaged,
device/trivial: rename nm_device_set_unmanaged_flags()
2016-01-13 12:03:47 +01:00
unmanaged
? NM_DEVICE_STATE_REASON_NOW_UNMANAGED
: NM_DEVICE_STATE_REASON_NOW_MANAGED);
device: refactor setting unmanaged based on device-spec
2015-09-15 23:53:46 +02:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
void
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_by_user_udev (NMDevice *self)
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
{
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
int ifindex;
gboolean platform_unmanaged = FALSE;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
ifindex = self->_priv->ifindex;
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
if ( ifindex <= 0
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
|| !nm_platform_link_get_unmanaged (nm_device_get_platform (self), ifindex, &platform_unmanaged))
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
return;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
nm_device_set_unmanaged_by_flags (self,
NM_UNMANAGED_USER_UDEV,
platform_unmanaged,
NM_DEVICE_STATE_REASON_USER_REQUESTED);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: turn link_changed() into a proper virtual function
2013-07-27 10:41:44 +02:00
device: add configuration option to mark devices as unmanaged We already have various ways to mark a device as unmanaged. 1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus at runtime. 2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and keyfile.unmanaged-devices in NetworkManager.conf. 3) at runtime, via D-Bus. This is persisted in the run state file and persists restarts (but not reboot). This adds another way via NetworkManager.conf file. Note that the existing keyfile.unmanaged-devices (above 2) is also a configuration optin in NetworkManager.conf. However it has various downsides: - it cannot be overwritten at runtime (see commit c210134bd58ea40ee3458aff27ab41958e1f48b4). - you can only explicitly mark a device as unmanaged. That means, you cannot use it to manage a device which is unmanaged due to a udev rule. - the name "keyfile.*" sounds like it's only relevant for the keyfile settings plugin. Nowadays the keyfile plugin is always loaded, so the option applies to NetworkManager in general. https://github.com/NetworkManager/NetworkManager/pull/29
2017-09-26 16:28:49 +02:00
void
nm_device_set_unmanaged_by_user_conf (NMDevice *self)
{
gboolean value;
NMUnmanFlagOp set_op;
value = nm_config_data_get_device_config_boolean (NM_CONFIG_GET_DATA,
NM_CONFIG_KEYFILE_KEY_DEVICE_MANAGED,
self,
-1,
TRUE);
switch (value) {
case TRUE:
set_op = NM_UNMAN_FLAG_OP_SET_MANAGED;
break;
case FALSE:
set_op = NM_UNMAN_FLAG_OP_SET_UNMANAGED;
break;
default:
set_op = NM_UNMAN_FLAG_OP_FORGET;
break;
}
nm_device_set_unmanaged_by_flags (self,
NM_UNMANAGED_USER_CONF,
set_op,
NM_DEVICE_STATE_REASON_USER_REQUESTED);
}
core/trivial: move code
2015-11-05 02:28:34 +01:00
void
device/trivial: rename nm_device_set_unmanaged_flags()
2016-01-13 12:03:47 +01:00
nm_device_set_unmanaged_by_quitting (NMDevice *self)
core/trivial: move code
2015-11-05 02:28:34 +01:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: use the REMOVED only when unmanaging an active device while quitting For the devices that are not active we still want to run the cleanup path. Fixes: 3e2fce288aee2dd012c5d7af8aaa4e59b2e5e747
2016-01-14 17:45:54 +01:00
gboolean need_deactivate = nm_device_is_activating (self) ||
priv->state == NM_DEVICE_STATE_ACTIVATED;
core/trivial: move code
2015-11-05 02:28:34 +01:00
/* It's OK to block here because we're quitting */
device: use the REMOVED only when unmanaging an active device while quitting For the devices that are not active we still want to run the cleanup path. Fixes: 3e2fce288aee2dd012c5d7af8aaa4e59b2e5e747
2016-01-14 17:45:54 +01:00
if (need_deactivate)
core/trivial: move code
2015-11-05 02:28:34 +01:00
_set_state_full (self, NM_DEVICE_STATE_DEACTIVATING, NM_DEVICE_STATE_REASON_NOW_UNMANAGED, TRUE);
device/trivial: rename nm_device_set_unmanaged_flags()
2016-01-13 12:03:47 +01:00
nm_device_set_unmanaged_by_flags (self,
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
NM_UNMANAGED_QUITTING,
device/trivial: rename nm_device_set_unmanaged_flags()
2016-01-13 12:03:47 +01:00
TRUE,
need_deactivate ? NM_DEVICE_STATE_REASON_REMOVED
: NM_DEVICE_STATE_REASON_NOW_UNMANAGED);
core/trivial: move code
2015-11-05 02:28:34 +01:00
}
/*****************************************************************************/
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
void
libnm-core: change all mac-address properties to G_TYPE_STRING Make all mac-address properties (including NMSettingBluetooth:bdaddr, NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be strings, using _nm_setting_class_transform_property() to handle translating to/from binary form when dealing with D-Bus. Update everything accordingly for the change, and also add a test for transformed setting properties to test-general.
2014-07-30 10:57:45 -04:00
nm_device_set_dhcp_anycast_address (NMDevice *self, const char *addr)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
NMDevicePrivate *priv;
devices: make constructors take an NMPlatformLink Rather than passing UDI, ifname, and driver name to the device constructors as separate arguments, just pass the NMPlatformLink instead and let it parse them out. Virtual types still take UDI and ifname separately, since we create fake NMDevices for them for autoactivating connections. That's weird in other ways too though, so perhaps this should be revisted.
2013-05-29 12:57:13 -03:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
libnm-core: change all mac-address properties to G_TYPE_STRING Make all mac-address properties (including NMSettingBluetooth:bdaddr, NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be strings, using _nm_setting_class_transform_property() to handle translating to/from binary form when dealing with D-Bus. Update everything accordingly for the change, and also add a test for transformed setting properties to test-general.
2014-07-30 10:57:45 -04:00
g_return_if_fail (!addr || nm_utils_hwaddr_valid (addr, ETH_ALEN));
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
libnm-core: change all mac-address properties to G_TYPE_STRING Make all mac-address properties (including NMSettingBluetooth:bdaddr, NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be strings, using _nm_setting_class_transform_property() to handle translating to/from binary form when dealing with D-Bus. Update everything accordingly for the change, and also add a test for transformed setting properties to test-general.
2014-07-30 10:57:45 -04:00
g_free (priv->dhcp_anycast_address);
priv->dhcp_anycast_address = g_strdup (addr);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
void
nm_device_reapply_settings_immediately (NMDevice *self)
{
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
NMConnection *applied_connection;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
NMSettingsConnection *settings_connection;
NMDeviceState state;
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
NMSettingConnection *s_con_settings;
NMSettingConnection *s_con_applied;
const char *zone;
NMMetered metered;
core: add version-id to NMActiveConnection This field will be later used by NMDevice's Reapply and GetAppliedConnection methods. The usecase is to first fetch the currently applied connection, adjust it and reapply it. Using the version-id, a concurrent modification can be detected and Reapply can reject the invocation.
2016-02-11 08:36:39 +01:00
guint64 version_id;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
state = nm_device_get_state (self);
if ( state <= NM_DEVICE_STATE_DISCONNECTED
|| state > NM_DEVICE_STATE_ACTIVATED)
return;
applied_connection = nm_device_get_applied_connection (self);
settings_connection = nm_device_get_settings_connection (self);
if (!nm_settings_connection_has_unmodified_applied_connection (settings_connection,
applied_connection,
NM_SETTING_COMPARE_FLAG_IGNORE_REAPPLY_IMMEDIATELY))
return;
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
s_con_settings = nm_connection_get_setting_connection ((NMConnection *) settings_connection);
s_con_applied = nm_connection_get_setting_connection (applied_connection);
if (g_strcmp0 ((zone = nm_setting_connection_get_zone (s_con_settings)),
nm_setting_connection_get_zone (s_con_applied)) != 0) {
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
version_id = nm_active_connection_version_id_bump ((NMActiveConnection *) self->_priv->act_request);
all: use "unsigned long" instead of "long unsigned"
2017-03-14 11:15:05 +01:00
_LOGD (LOGD_DEVICE, "reapply setting: zone = %s%s%s (version-id %llu)", NM_PRINT_FMT_QUOTE_STRING (zone), (unsigned long long) version_id);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_object_set (G_OBJECT (s_con_applied),
NM_SETTING_CONNECTION_ZONE, zone,
NULL);
nm_device_update_firewall_zone (self);
}
if ((metered = nm_setting_connection_get_metered (s_con_settings)) != nm_setting_connection_get_metered (s_con_applied)) {
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
version_id = nm_active_connection_version_id_bump ((NMActiveConnection *) self->_priv->act_request);
all: use "unsigned long" instead of "long unsigned"
2017-03-14 11:15:05 +01:00
_LOGD (LOGD_DEVICE, "reapply setting: metered = %d (version-id %llu)", (int) metered, (unsigned long long) version_id);
device: refactor reapply_connection() Reapplying a connection should not be done by iterating over and (unsorted) @diffs array. Instead the order matters! E.g. first layer 2 before IP settings. Thus extracting those individual updates on a per-setting base to different reapply_*() functions is more complicated, albeit incorrect in complex cases. We need full control over how to reapply changes, one after the other. Also, once we start applying changes, we cannot really abort on error. We can only continue best-effort and hope for the best. Also, always reapply certain settings, even if the configuration doesn't change. That means, if the user externally deletes a static IP address, he can call reapply() to restore it. Even though he doesn't provide a different setting to apply. Also revert the changes to nm_device_reapply_settings_immediately(). Effectively there is little code that can be reused. Add audit logging.
2016-01-07 11:55:44 +01:00
g_object_set (G_OBJECT (s_con_applied),
NM_SETTING_CONNECTION_METERED, metered,
NULL);
nm_device_update_metered (self);
}
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
}
void
nm_device_update_firewall_zone (NMDevice *self)
{
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
NMDevicePrivate *priv;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
if ( priv->fw_state >= FIREWALL_STATE_INITIALIZED
&& !nm_device_sys_iface_state_is_external (self))
fw_change_zone (self);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
}
policy: update device's metered property when connection changes If the metered property of a connection is changed, an activated device associated to the connection must be updated immediately with the new metered value. https://bugzilla.gnome.org/show_bug.cgi?id=754409
2015-09-07 12:06:27 +02:00
void
core: update device 'metered' property on connection state change The metered property of a NMDevice that reaches the activated state is copied from the active connection and if its value is 'unknown' some heuristics are used to guess the actual value. When the connection is torn down the metered property is reset to 'unknown'.
2015-04-30 14:18:14 +02:00
nm_device_update_metered (NMDevice *self)
{
#define NM_METERED_INVALID ((NMMetered) -1)
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMSettingConnection *setting;
NMMetered conn_value, value = NM_METERED_INVALID;
NMConnection *connection = NULL;
NMDeviceState state;
g_return_if_fail (NM_IS_DEVICE (self));
state = nm_device_get_state (self);
if ( state <= NM_DEVICE_STATE_DISCONNECTED
|| state > NM_DEVICE_STATE_ACTIVATED)
value = NM_METERED_UNKNOWN;
if (value == NM_METERED_INVALID) {
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
core: update device 'metered' property on connection state change The metered property of a NMDevice that reaches the activated state is copied from the active connection and if its value is 'unknown' some heuristics are used to guess the actual value. When the connection is torn down the metered property is reset to 'unknown'.
2015-04-30 14:18:14 +02:00
if (connection) {
setting = nm_connection_get_setting_connection (connection);
if (setting) {
conn_value = nm_setting_connection_get_metered (setting);
if (conn_value != NM_METERED_UNKNOWN)
value = conn_value;
}
}
}
/* Try to guess a value using the metered flag in IP configuration */
if (value == NM_METERED_INVALID) {
if ( priv->ip4_config
&& priv->ip4_state == IP_DONE
&& nm_ip4_config_get_metered (priv->ip4_config))
value = NM_METERED_GUESS_YES;
}
/* Otherwise look at connection type */
if (value == NM_METERED_INVALID) {
if ( nm_connection_is_type (connection, NM_SETTING_GSM_SETTING_NAME)
|| nm_connection_is_type (connection, NM_SETTING_CDMA_SETTING_NAME))
value = NM_METERED_GUESS_YES;
else
value = NM_METERED_GUESS_NO;
}
if (value != priv->metered) {
_LOGD (LOGD_DEVICE, "set metered value %d", value);
priv->metered = value;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_METERED);
core: update device 'metered' property on connection state change The metered property of a NMDevice that reaches the activated state is copied from the active connection and if its value is 'unknown' some heuristics are used to guess the actual value. When the connection is torn down the metered property is reset to 'unknown'.
2015-04-30 14:18:14 +02:00
}
}
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
static gboolean
_nm_device_check_connection_available (NMDevice *self,
NMConnection *connection,
NMDeviceCheckConAvailableFlags flags,
const char *specific_object)
{
NMDeviceState state;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
/* an unrealized software device is always available, hardware devices never. */
if (!nm_device_is_real (self)) {
if (nm_device_is_software (self))
return nm_device_check_connection_compatible (self, connection);
return FALSE;
}
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
state = nm_device_get_state (self);
if (state < NM_DEVICE_STATE_UNMANAGED)
return FALSE;
if ( state < NM_DEVICE_STATE_UNAVAILABLE
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
&& ( ( !NM_FLAGS_ANY (flags, NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST)
&& !nm_device_get_managed (self, FALSE))
|| ( NM_FLAGS_ANY (flags, NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST)
&& !nm_device_get_managed (self, TRUE))))
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
return FALSE;
if ( state < NM_DEVICE_STATE_DISCONNECTED
core: create devices first and realize them later Unrealized devices aren't backed by kernel resources and so won't know all of their attributes. That means three things: 1) they must update their attributes when they become realized 2) they must clear those attributes when unrealized 3) they must be looser in checking compatible connections until they are realized This requires that the setup() function be split into two parts, start & finish, because finish must be run after add_device() Also, we can simplify whether to pay attention to 'recheck-assume', which is now dependent on priv->is_nm_owned, because the only case where NM should *not* listen for the 'recheck-assume' signal is when the device is a software device created by NM itself. That logic was previously spread across the callers of add_device() but is now consolidated into nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
2014-09-24 16:58:07 -05:00
&& !nm_device_is_software (self)
device: add NM_DEVICE_CHECK_DEV_AVAILABLE_FOR_USER_REQUEST flag This generalizes _NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER.
2015-12-09 12:08:40 +01:00
&& ( ( !NM_FLAGS_ANY (flags, NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST)
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
&& !nm_device_is_available (self, NM_DEVICE_CHECK_DEV_AVAILABLE_NONE))
device: add NM_DEVICE_CHECK_DEV_AVAILABLE_FOR_USER_REQUEST flag This generalizes _NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER.
2015-12-09 12:08:40 +01:00
|| ( NM_FLAGS_ANY (flags, NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST)
&& !nm_device_is_available (self, NM_DEVICE_CHECK_DEV_AVAILABLE_FOR_USER_REQUEST))))
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
return FALSE;
if (!nm_device_check_connection_compatible (self, connection))
return FALSE;
return NM_DEVICE_GET_CLASS (self)->check_connection_available (self, connection, flags, specific_object);
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/**
device: eliminate direct calls to check_connection_available() in favor of nm_device_check_connection_available() It was confusing to understand the difference between calling nm_device_connection_is_available() and check_connection_available(), they behaved similar, but not really the same. Especially nm_device_connection_is_available() would look first into @available_connetions, and might call check_connection_available() itself. Whereas @available_connetions was also populated by testing check_connection_available(). This interrelation makes it hard to understand when nm_device_connection_is_available() returned true. Rename nm_device_connection_is_available() to nm_device_check_connection_available() and remove all direct calls of check_connection_available() in favor of the wrapper nm_device_check_connection_available(). Now we only call nm_device_check_connection_available() with different parameters (@flags and @specific_object). We also have the additional guarantee that specifying more @flags will widen the result and making a connection "more" available, while specifying a @specific_object will restrict it. This also changes behavior in several cases. For example before nm_device_connection_is_available() for user-requests would always declare matching connections available on Wi-Fi devices (only) regardless of the device state. Now the device state gets consistently considered. For default-unmanaged devices it also changes behavior in complicated ways, because before we would put connections into @available_connetions for every device-state, but nm_device_connection_is_available() had a special over-ride only for unmanaged-state. This also fixes a bug, that user can activate an unavailable Wi-Fi device: nmcli radio wifi off nmcli connection up wlan0
2015-01-16 16:43:48 +01:00
* nm_device_check_connection_available():
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the #NMDevice
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
* @connection: the #NMConnection to check for availability
device: eliminate direct calls to check_connection_available() in favor of nm_device_check_connection_available() It was confusing to understand the difference between calling nm_device_connection_is_available() and check_connection_available(), they behaved similar, but not really the same. Especially nm_device_connection_is_available() would look first into @available_connetions, and might call check_connection_available() itself. Whereas @available_connetions was also populated by testing check_connection_available(). This interrelation makes it hard to understand when nm_device_connection_is_available() returned true. Rename nm_device_connection_is_available() to nm_device_check_connection_available() and remove all direct calls of check_connection_available() in favor of the wrapper nm_device_check_connection_available(). Now we only call nm_device_check_connection_available() with different parameters (@flags and @specific_object). We also have the additional guarantee that specifying more @flags will widen the result and making a connection "more" available, while specifying a @specific_object will restrict it. This also changes behavior in several cases. For example before nm_device_connection_is_available() for user-requests would always declare matching connections available on Wi-Fi devices (only) regardless of the device state. Now the device state gets consistently considered. For default-unmanaged devices it also changes behavior in complicated ways, because before we would put connections into @available_connetions for every device-state, but nm_device_connection_is_available() had a special over-ride only for unmanaged-state. This also fixes a bug, that user can activate an unavailable Wi-Fi device: nmcli radio wifi off nmcli connection up wlan0
2015-01-16 16:43:48 +01:00
* @flags: flags to affect the decision making of whether a connection
* is available. Adding a flag can only make a connection more available,
* not less.
* @specific_object: a device type dependent argument to further
* filter the result. Passing a non %NULL specific object can only reduce
* the availability of a connection.
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*
device: eliminate direct calls to check_connection_available() in favor of nm_device_check_connection_available() It was confusing to understand the difference between calling nm_device_connection_is_available() and check_connection_available(), they behaved similar, but not really the same. Especially nm_device_connection_is_available() would look first into @available_connetions, and might call check_connection_available() itself. Whereas @available_connetions was also populated by testing check_connection_available(). This interrelation makes it hard to understand when nm_device_connection_is_available() returned true. Rename nm_device_connection_is_available() to nm_device_check_connection_available() and remove all direct calls of check_connection_available() in favor of the wrapper nm_device_check_connection_available(). Now we only call nm_device_check_connection_available() with different parameters (@flags and @specific_object). We also have the additional guarantee that specifying more @flags will widen the result and making a connection "more" available, while specifying a @specific_object will restrict it. This also changes behavior in several cases. For example before nm_device_connection_is_available() for user-requests would always declare matching connections available on Wi-Fi devices (only) regardless of the device state. Now the device state gets consistently considered. For default-unmanaged devices it also changes behavior in complicated ways, because before we would put connections into @available_connetions for every device-state, but nm_device_connection_is_available() had a special over-ride only for unmanaged-state. This also fixes a bug, that user can activate an unavailable Wi-Fi device: nmcli radio wifi off nmcli connection up wlan0
2015-01-16 16:43:48 +01:00
* Check if @connection is available to be activated on @self.
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* Returns: %TRUE if @connection can be activated on @self
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*/
gboolean
device: eliminate direct calls to check_connection_available() in favor of nm_device_check_connection_available() It was confusing to understand the difference between calling nm_device_connection_is_available() and check_connection_available(), they behaved similar, but not really the same. Especially nm_device_connection_is_available() would look first into @available_connetions, and might call check_connection_available() itself. Whereas @available_connetions was also populated by testing check_connection_available(). This interrelation makes it hard to understand when nm_device_connection_is_available() returned true. Rename nm_device_connection_is_available() to nm_device_check_connection_available() and remove all direct calls of check_connection_available() in favor of the wrapper nm_device_check_connection_available(). Now we only call nm_device_check_connection_available() with different parameters (@flags and @specific_object). We also have the additional guarantee that specifying more @flags will widen the result and making a connection "more" available, while specifying a @specific_object will restrict it. This also changes behavior in several cases. For example before nm_device_connection_is_available() for user-requests would always declare matching connections available on Wi-Fi devices (only) regardless of the device state. Now the device state gets consistently considered. For default-unmanaged devices it also changes behavior in complicated ways, because before we would put connections into @available_connetions for every device-state, but nm_device_connection_is_available() had a special over-ride only for unmanaged-state. This also fixes a bug, that user can activate an unavailable Wi-Fi device: nmcli radio wifi off nmcli connection up wlan0
2015-01-16 16:43:48 +01:00
nm_device_check_connection_available (NMDevice *self,
NMConnection *connection,
NMDeviceCheckConAvailableFlags flags,
const char *specific_object)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
gboolean available;
device: refactor nm_device_connection_is_available() No functional change, but refactor the function to return early.
2014-12-08 12:15:02 +01:00
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
available = _nm_device_check_connection_available (self, connection, flags, specific_object);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
#if NM_MORE_ASSERTS >= 2
{
/* The meaning of the flags is so that *adding* a flag relaxes a condition, thus making
* the device *more* available. Assert against that requirement by testing all the flags. */
NMDeviceCheckConAvailableFlags i, j, k;
gboolean available_all[NM_DEVICE_CHECK_CON_AVAILABLE_ALL + 1] = { FALSE };
for (i = 0; i <= NM_DEVICE_CHECK_CON_AVAILABLE_ALL; i++)
available_all[i] = _nm_device_check_connection_available (self, connection, i, specific_object);
for (i = 0; i <= NM_DEVICE_CHECK_CON_AVAILABLE_ALL; i++) {
for (j = 1; j <= NM_DEVICE_CHECK_CON_AVAILABLE_ALL; j <<= 1) {
if (NM_FLAGS_HAS (i, j)) {
k = i & ~j;
nm_assert ( available_all[i] == available_all[k]
|| available_all[i]);
}
}
}
}
#endif
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: add assertion to consistency of nm_device_check_connection_available()
2015-10-05 13:42:24 +02:00
return available;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
static gboolean
available_connections_del_all (NMDevice *self)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
if (g_hash_table_size (self->_priv->available_connections) == 0)
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
return FALSE;
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
g_hash_table_remove_all (self->_priv->available_connections);
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
return TRUE;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
static gboolean
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
available_connections_add (NMDevice *self, NMConnection *connection)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
return nm_g_hash_table_add (self->_priv->available_connections, g_object_ref (connection));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static gboolean
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
available_connections_del (NMDevice *self, NMConnection *connection)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
return g_hash_table_remove (self->_priv->available_connections, connection);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
check_connection_available (NMDevice *self,
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
NMConnection *connection,
device: add flags argument to check_connection_available()
2015-01-16 14:54:11 +01:00
NMDeviceCheckConAvailableFlags flags,
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
const char *specific_object)
{
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE(self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Connections which require a network connection are not available when
* the device has no carrier, even with ignore-carrer=TRUE.
*/
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
if ( priv->carrier
|| !connection_requires_carrier (connection))
return TRUE;
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
if ( NM_FLAGS_HAS (flags, _NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_WAITING_CARRIER)
&& priv->carrier_wait_id != 0) {
/* The device has no carrier though the connection requires it.
*
* If we are still waiting for carrier, the connection is available
* for an explicit user-request. */
return TRUE;
}
device: refactor how master device's set is_available() Previously, master device types like bridge, bond, and team would overwrite is_available() and check_connection_available() and always return TRUE. The device already expresses via nm_device_is_master() that it is of a master kind. Refactor the code, so, instead of having these device types overwrite is_available() and check_connection_available(), let the parents implementation react on nm_device_is_master(). There is no change in behavior at all. Instead, the knowledge how to treat a master device moves from the device implementation to the parent class.
2017-06-02 00:01:26 +02:00
/* master types are always available even without carrier.
* Making connection non-available would un-enslave slaves which
* is not desired. */
if (nm_device_is_master (self))
return TRUE;
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
return FALSE;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_recheck_available_connections (NMDevice *self)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
NMDevicePrivate *priv;
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
NMSettingsConnection *const*connections;
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
gboolean changed = FALSE;
GHashTableIter h_iter;
NMConnection *connection;
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
guint i;
gs_unref_hashtable GHashTable *prune_list = NULL;
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
priv = NM_DEVICE_GET_PRIVATE(self);
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
if (g_hash_table_size (priv->available_connections) > 0) {
prune_list = g_hash_table_new (g_direct_hash, g_direct_equal);
g_hash_table_iter_init (&h_iter, priv->available_connections);
while (g_hash_table_iter_next (&h_iter, (gpointer *) &connection, NULL))
g_hash_table_add (prune_list, connection);
}
connections = nm_settings_get_connections (priv->settings, NULL);
for (i = 0; connections[i]; i++) {
connection = (NMConnection *) connections[i];
if (nm_device_check_connection_available (self,
connection,
NM_DEVICE_CHECK_CON_AVAILABLE_NONE,
NULL)) {
if (available_connections_add (self, connection))
changed = TRUE;
if (prune_list)
g_hash_table_remove (prune_list, connection);
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
}
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
}
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
if (prune_list) {
g_hash_table_iter_init (&h_iter, prune_list);
while (g_hash_table_iter_next (&h_iter, (gpointer *) &connection, NULL)) {
if (available_connections_del (self, connection))
changed = TRUE;
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
device: remove unrealized device without connections on idle handler Emitting the NM_DEVICE_REMOVED signal can cause the destruction of the device, thus it should be emitted on an idle handler.
2016-01-19 11:33:33 +01:00
device: always do a unrealized delete check when rechecking available connections It could be that what changed is the unrealize flag, not the number available connections. That could happen when a last connection for a software device is removed.
2016-02-15 21:14:22 +01:00
if (changed)
device: drop available_connections_notify() and call _notify() directly
2016-04-13 14:59:43 +02:00
_notify (self, PROP_AVAILABLE_CONNECTIONS);
device: always do a unrealized delete check when rechecking available connections It could be that what changed is the unrealize flag, not the number available connections. That could happen when a last connection for a software device is removed.
2016-02-15 21:14:22 +01:00
available_connections_check_delete_unrealized (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: add "Autoconnect" property to NMDevice It is bound to autoconnect_inhibit private variable (has opposite meaning). While 'Autoconnect' is TRUE (default value) the device can automatically activate a connection. If it is changed to FALSE, the device will not auto-activate until 'Autoconnect' is TRUE again. Disconnect() method sets 'Autoconnect' to FALSE. NMPolicy monitors the property and schedules auto activation when FALSE->TRUE transition is made.
2012-05-14 15:32:54 +02:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/**
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
* nm_device_get_best_connection:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the #NMDevice
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
* @specific_object: a specific object path if any
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
* @error: reason why no connection was returned
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
* Returns a connection that's most suitable for user-initiated activation
* of a device, optionally with a given specific object.
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
* Returns: the #NMSettingsConnection or %NULL (setting an @error)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
*/
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
NMSettingsConnection *
nm_device_get_best_connection (NMDevice *self,
const char *specific_object,
GError **error)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
NMSettingsConnection *connection = NULL;
NMSettingsConnection *candidate;
guint64 best_timestamp = 0;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
GHashTableIter iter;
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
g_hash_table_iter_init (&iter, priv->available_connections);
while (g_hash_table_iter_next (&iter, (gpointer) &candidate, NULL)) {
guint64 candidate_timestamp = 0;
/* If a specific object is given, only include connections that are
* compatible with it.
*/
if ( specific_object /* << Optimization: we know that the connection is available without @specific_object. */
&& !nm_device_check_connection_available (self,
NM_CONNECTION (candidate),
_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST,
specific_object))
continue;
nm_settings_connection_get_timestamp (candidate, &candidate_timestamp);
if (!connection || (candidate_timestamp > best_timestamp)) {
connection = candidate;
best_timestamp = candidate_timestamp;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
}
device: _get_available_connections() with _get_best_connection() We'll need to share the best conneciton logic and it's the only caller of nm_device_get_available_connections(). Let's just move it all to NMDevice and provide the best connection from there instead.
2016-03-23 10:35:55 +01:00
if (!connection) {
g_set_error (error, NM_MANAGER_ERROR, NM_MANAGER_ERROR_UNKNOWN_CONNECTION,
"The device '%s' has no connections available for activation.",
nm_device_get_iface (self));
}
return connection;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
cp_connection_added_or_updated (NMDevice *self, NMConnection *connection)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
gboolean changed;
device: refactor cp_connection* functions to use @self pointer
2016-01-14 18:18:25 +01:00
g_return_if_fail (NM_IS_DEVICE (self));
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
g_return_if_fail (NM_IS_SETTINGS_CONNECTION (connection));
device: refactor cp_connection* functions to use @self pointer
2016-01-14 18:18:25 +01:00
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
if (nm_device_check_connection_available (self,
connection,
device: for available connections check whether they are available for user-request But not with ignoring-carrier and ignoring-ap.
2016-01-20 17:59:26 +01:00
_NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST,
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
NULL))
changed = available_connections_add (self, connection);
else
changed = available_connections_del (self, connection);
device: refactor cp_connection* functions to use @self pointer
2016-01-14 18:18:25 +01:00
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
if (changed) {
device: drop available_connections_notify() and call _notify() directly
2016-04-13 14:59:43 +02:00
_notify (self, PROP_AVAILABLE_CONNECTIONS);
device/trivial: rename functions for available-connections
2016-01-20 18:02:34 +01:00
available_connections_check_delete_unrealized (self);
device: cleanup unrealized device without connection During nm_device_unrealize(), the connection might still have some connections that only get removed later. We must garbage collect unrealized devices when they loose their available-connections, not during unrealize. Fixes: 436ec5b8e37ca2e5fc0f8d09a4c5f09cf406b4a5
2016-01-14 18:04:42 +01:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
static void
cp_connection_added (NMConnectionProvider *cp, NMConnection *connection, gpointer user_data)
{
cp_connection_added_or_updated (user_data, connection);
}
static void
cp_connection_updated (NMConnectionProvider *cp, NMConnection *connection, gboolean by_user, gpointer user_data)
{
cp_connection_added_or_updated (user_data, connection);
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
cp_connection_removed (NMConnectionProvider *cp, NMConnection *connection, gpointer user_data)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
device: refactor cp_connection* functions to use @self pointer
2016-01-14 18:18:25 +01:00
NMDevice *self = user_data;
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
device: refactor cp_connection* functions to use @self pointer
2016-01-14 18:18:25 +01:00
g_return_if_fail (NM_IS_DEVICE (self));
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
if (available_connections_del (self, connection)) {
device: drop available_connections_notify() and call _notify() directly
2016-04-13 14:59:43 +02:00
_notify (self, PROP_AVAILABLE_CONNECTIONS);
device/trivial: rename functions for available-connections
2016-01-20 18:02:34 +01:00
available_connections_check_delete_unrealized (self);
device: cleanup unrealized device without connection During nm_device_unrealize(), the connection might still have some connections that only get removed later. We must garbage collect unrealized devices when they loose their available-connections, not during unrealize. Fixes: 436ec5b8e37ca2e5fc0f8d09a4c5f09cf406b4a5
2016-01-14 18:04:42 +01:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: add IS_MASTER property to NMDevice We can't just check whether there are slaves or not, because the master device may be started before any slaves exist, and the slaves get added later.
2013-01-24 17:47:59 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_supports_vlans (NMDevice *self)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
return nm_platform_link_supports_vlans (nm_device_get_platform (self), nm_device_get_ifindex (self));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
devices: add :master property Add a property to NMDevice that can be used to tell whether the device is enslaved, and if so what its master is. This is currently internal-only, but it could be exported later perhaps.
2014-01-02 14:46:02 -05:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/**
* nm_device_add_pending_action():
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the #NMDevice to add the pending action to
device: don't clone pending-action string All callers either use a static @action argument or keep a clone of the string that lives as long as the action is pending. So, save cloning the string.
2017-01-27 15:41:25 +01:00
* @action: a static string that identifies the action. The string instance must
* stay valid until the pending action is removed (that is, the string is
* not cloned, but ownership stays with the caller).
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
* @assert_not_yet_pending: if %TRUE, assert that the @action is currently not yet pending.
* Otherwise, ignore duplicate scheduling of the same action silently.
*
* Adds a pending action to the device.
*
* Returns: %TRUE if the action was added (and not already added before). %FALSE
* if the same action is already scheduled. In the latter case, the action was not scheduled
* a second time.
*/
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_add_pending_action (NMDevice *self, const char *action, gboolean assert_not_yet_pending)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
GSList *iter;
guint count = 0;
core: reorganize hw-address properties Now that NMDevice reads the hwaddr directly from netlink, it's silly to have every device subtype maintain its own hw-address property (using data that it gets from the NMDevice base class). Remove all the device-specific hw-address properties, and add one to NMDevice instead. (Because of the way nm-properties-changed-signal works, this has no effect on the D-Bus API.) Subclasses now call nm_device_get_hw_address() in places where they used to just refer to priv->hw_addr (and to simplify this, we now allow passing NULL for the out length parameter, since the subclasses almost always know what the length will be already). Also reorganize/simplify a few other methods to take advantage of the fact that NMDevice is now keeping track of the hw-address directly. https://bugzilla.gnome.org/show_bug.cgi?id=699391
2013-05-01 09:28:16 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_return_val_if_fail (action, FALSE);
core: add NMManager:startup property 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.
2013-08-13 17:45:34 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Check if the action is already pending. Cannot add duplicate actions */
for (iter = priv->pending_actions; iter; iter = iter->next) {
if (!strcmp (action, iter->data)) {
if (assert_not_yet_pending) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_DEVICE, "add_pending_action (%d): '%s' already pending",
count + g_slist_length (iter), action);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_return_val_if_reached (FALSE);
} else {
device: downgrade logging messages about (non) pending action Adding/Removing a pending action with assert_not_yet_pending/ assert_is_pending means that we expect that no action is taken. Downgrade the logging level in those cases to <trace>.
2017-05-12 16:48:57 +02:00
_LOGT (LOGD_DEVICE, "add_pending_action (%d): '%s' already pending (expected)",
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
count + g_slist_length (iter), action);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
return FALSE;
}
count++;
}
core: move state-changed signal to nm-device.c
2011-11-18 00:09:37 -06:00
device: prepend pending actions list The order doesn't matter, so prepend instead of append new items to the pending-actions list.
2017-02-02 12:09:48 +01:00
priv->pending_actions = g_slist_prepend (priv->pending_actions, (char *) action);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
count++;
core: move NMDeviceInterfaceError to nm-device.c
2011-11-18 00:05:37 -06:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "add_pending_action (%d): '%s'", count, action);
core: add generic device authorization request signal Allows devices to generically request authorization from the manager for whatever operation they want, and allows us to keep the devices from including the auth code directly.
2012-06-01 15:27:39 -05:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
if (count == 1)
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_HAS_PENDING_ACTION);
core: add device IPv4 and IPv6 config change signals We'll use these later to pull the DNS manager code out of the device class and into the policy.
2012-05-29 09:56:50 -05:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
return TRUE;
}
core: add device IPv4 and IPv6 config change signals We'll use these later to pull the DNS manager code out of the device class and into the policy.
2012-05-29 09:56:50 -05:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/**
* nm_device_remove_pending_action():
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: the #NMDevice to remove the pending action from
device: don't clone pending-action string All callers either use a static @action argument or keep a clone of the string that lives as long as the action is pending. So, save cloning the string.
2017-01-27 15:41:25 +01:00
* @action: a string that identifies the action.
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
* @assert_is_pending: if %TRUE, assert that the @action is pending.
* If %FALSE, don't do anything if the current action is not pending and
* return %FALSE.
*
* Removes a pending action previously added by nm_device_add_pending_action().
*
* Returns: whether the @action was pending and is now removed.
*/
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_remove_pending_action (NMDevice *self, const char *action, gboolean assert_is_pending)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
device: assert for valid device argument in nm_device_remove_pending_action() Coverity complains in nm-active-connection.c: 996 if (priv->pending_activation_id) { CID 59368 (#1 of 1): Dereference after null check (FORWARD_NULL)4. var_deref_model: Passing null pointer priv->device to nm_device_remove_pending_action, which dereferences it. [show details] 997 nm_device_remove_pending_action (priv->device, priv->pending_activation_id, TRUE); 998 g_clear_pointer (&priv->pending_activation_id, g_free); 999 }
2016-03-04 08:46:51 +01:00
NMDevicePrivate *priv;
device: avoid removing a list element while iterating it
2015-11-05 16:19:01 +01:00
GSList *iter, *next;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
guint count = 0;
core: allow devices to indicate when they should be removed Devices created by plugins will use this to indicate when their backing resources have disappeared, at which point the manager should remove them.
2014-02-10 08:49:47 -06:00
device: assert for valid device argument in nm_device_remove_pending_action() Coverity complains in nm-active-connection.c: 996 if (priv->pending_activation_id) { CID 59368 (#1 of 1): Dereference after null check (FORWARD_NULL)4. var_deref_model: Passing null pointer priv->device to nm_device_remove_pending_action, which dereferences it. [show details] 997 nm_device_remove_pending_action (priv->device, priv->pending_activation_id, TRUE); 998 g_clear_pointer (&priv->pending_activation_id, g_free); 999 }
2016-03-04 08:46:51 +01:00
g_return_val_if_fail (self, FALSE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_return_val_if_fail (action, FALSE);
core: consolidate auto-activation recheck signals Add a generic signal that devices can use to indicate that something material in the network situation changed, and that auto-activation may now be possible. This reduces specific knowledge of device types in the policy.
2014-02-24 18:10:18 -06:00
device: assert for valid device argument in nm_device_remove_pending_action() Coverity complains in nm-active-connection.c: 996 if (priv->pending_activation_id) { CID 59368 (#1 of 1): Dereference after null check (FORWARD_NULL)4. var_deref_model: Passing null pointer priv->device to nm_device_remove_pending_action, which dereferences it. [show details] 997 nm_device_remove_pending_action (priv->device, priv->pending_activation_id, TRUE); 998 g_clear_pointer (&priv->pending_activation_id, g_free); 999 }
2016-03-04 08:46:51 +01:00
priv = NM_DEVICE_GET_PRIVATE (self);
device: avoid removing a list element while iterating it
2015-11-05 16:19:01 +01:00
for (iter = priv->pending_actions; iter; iter = next) {
next = iter->next;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
if (!strcmp (action, iter->data)) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "remove_pending_action (%d): '%s'",
count + g_slist_length (iter->next), /* length excluding 'iter' */
action);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv->pending_actions = g_slist_delete_link (priv->pending_actions, iter);
if (priv->pending_actions == NULL)
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_HAS_PENDING_ACTION);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
return TRUE;
}
count++;
}
core: re-attempt connection assumption when the device state changes If the initial attempt to assume a connection on a device fails, and the device remains un-activated, but then something changes its configuration externally, try to generate a new connection and assume that.
2014-05-28 10:18:34 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
if (assert_is_pending) {
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_DEVICE, "remove_pending_action (%d): '%s' not pending", count, action);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_return_val_if_reached (FALSE);
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
} else
device: downgrade logging messages about (non) pending action Adding/Removing a pending action with assert_not_yet_pending/ assert_is_pending means that we expect that no action is taken. Downgrade the logging level in those cases to <trace>.
2017-05-12 16:48:57 +02:00
_LOGT (LOGD_DEVICE, "remove_pending_action (%d): '%s' not pending (expected)", count, action);
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
return FALSE;
}
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_has_pending_action (NMDevice *self)
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: delay startup complete until device is initialized in platform Udev may be slow at startup and it may take a while until the device is visible in udev. Before that, there are no pending actions yet because the device is still in unmanaged state. Hack nm_device_has_pending_action() to indicate a pending action when the platform link is not yet initialized. We don't bother using nm_device_add_pending_action() to schedule a proper pending-action. It is simpler this way, also we precisely log about the state of NM_UNMANAGED_PLATFORM_INIT flag. The pending actions are implemented in their way mostly for logging purpose to understand what blocks a device. For NM_UNMANAGED_PLATFORM_INIT we have sufficient logging so no need for the overhead and effort. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-13 18:45:36 +01:00
if (priv->pending_actions)
return TRUE;
device: fix delay startup complete for unrealized devices Since commit 6845b9b80a9fcec9d2c9e7b56a37329f38089f2e ("device: delay startup complete until device is initialized in platform", we also wait for devices that are still initializing platform/UDEV. Obviously, that only applies to realized devices. Otherwise, an unrealized device is going to block startup complete. Fixes: 6845b9b80a9fcec9d2c9e7b56a37329f38089f2e
2017-09-29 17:08:55 +02:00
if ( nm_device_is_real (self)
&& nm_device_get_unmanaged_flags (self, NM_UNMANAGED_PLATFORM_INIT)) {
device: delay startup complete until device is initialized in platform Udev may be slow at startup and it may take a while until the device is visible in udev. Before that, there are no pending actions yet because the device is still in unmanaged state. Hack nm_device_has_pending_action() to indicate a pending action when the platform link is not yet initialized. We don't bother using nm_device_add_pending_action() to schedule a proper pending-action. It is simpler this way, also we precisely log about the state of NM_UNMANAGED_PLATFORM_INIT flag. The pending actions are implemented in their way mostly for logging purpose to understand what blocks a device. For NM_UNMANAGED_PLATFORM_INIT we have sufficient logging so no need for the overhead and effort. https://bugzilla.gnome.org/show_bug.cgi?id=779920
2017-03-13 18:45:36 +01:00
/* as long as the platform link is not yet initialized, we have a pending
* action. */
return TRUE;
}
return FALSE;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
static void
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
_cancel_activation (NMDevice *self)
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: use singleton nm_firewall_manager_get() throughout without taking additional ref No need to keep references of the singleton and take an additional ref when accessing nm_firewall_manager_get(). Especially, since the firewall manager instance was nowhere passed in from externally, it doesn't even sense for some vague testing purporse. Not to mention, that there are no tests that actually inject a firewall manager stub. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-02 15:19:58 +02:00
if (priv->fw_call) {
firewall: refactor callback handling in NMFirewallManager Refactor NMFirewallManager to have consistent semantics about asynchronous calls. - the callback is always invoked exactly once, but never synchronously when starting the operation. - while cancelling the request, the callback is invoked synchronously with respect to the cancel operation. - you can cancel a request once (and once only). - you cannot cancel the request once the callback is invoked. - when disposing the object with requests pending, the callbacks are invoked synchronously. - Add a callback argument to nm_firewall_manager_remove_from_zone(). Otherwise, the user never knows whether a call is still pending and cancellable (as complete operations cannot be cancelled). In fact, it makes no sense trying to cancel a call if you don't care about when it completes. - get rid of PENDING_CALL_DUMMY. The dummy callback allows cancellation any number of times. We want to catch wrong usage by asserting that an operation is only cancelled once. - nm_firewall_manager_cancel_call() doesn't need the manager argument. Either the call-id is valid (and has a valid pointer to the manager), or there is a bug and it is a dangling pointer.
2015-09-23 17:18:44 +02:00
nm_firewall_manager_cancel_call (priv->fw_call);
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
nm_assert (!priv->fw_call);
core: use singleton nm_firewall_manager_get() throughout without taking additional ref No need to keep references of the singleton and take an additional ref when accessing nm_firewall_manager_get(). Especially, since the firewall manager instance was nowhere passed in from externally, it doesn't even sense for some vague testing purporse. Not to mention, that there are no tests that actually inject a firewall manager stub. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-02 15:19:58 +02:00
priv->fw_call = NULL;
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
priv->fw_state = FIREWALL_STATE_INITIALIZED;
core: use singleton nm_firewall_manager_get() throughout without taking additional ref No need to keep references of the singleton and take an additional ref when accessing nm_firewall_manager_get(). Especially, since the firewall manager instance was nowhere passed in from externally, it doesn't even sense for some vague testing purporse. Not to mention, that there are no tests that actually inject a firewall manager stub. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-02 15:19:58 +02:00
}
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
ip_check_gw_ping_cleanup (self);
/* Break the activation chain */
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
activation_source_clear (self, AF_INET);
activation_source_clear (self, AF_INET6);
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
}
static void
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
_cleanup_generic_pre (NMDevice *self, CleanupType cleanup_type)
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
{
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
_cancel_activation (self);
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
if ( cleanup_type == CLEANUP_TYPE_DECONFIGURE
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
&& priv->fw_state >= FIREWALL_STATE_INITIALIZED
&& priv->fw_mgr
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
&& !nm_device_sys_iface_state_is_external (self)) {
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
nm_firewall_manager_remove_from_zone (priv->fw_mgr,
core: use singleton nm_firewall_manager_get() throughout without taking additional ref No need to keep references of the singleton and take an additional ref when accessing nm_firewall_manager_get(). Especially, since the firewall manager instance was nowhere passed in from externally, it doesn't even sense for some vague testing purporse. Not to mention, that there are no tests that actually inject a firewall manager stub. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-02 15:19:58 +02:00
nm_device_get_ip_iface (self),
firewall: refactor callback handling in NMFirewallManager Refactor NMFirewallManager to have consistent semantics about asynchronous calls. - the callback is always invoked exactly once, but never synchronously when starting the operation. - while cancelling the request, the callback is invoked synchronously with respect to the cancel operation. - you can cancel a request once (and once only). - you cannot cancel the request once the callback is invoked. - when disposing the object with requests pending, the callbacks are invoked synchronously. - Add a callback argument to nm_firewall_manager_remove_from_zone(). Otherwise, the user never knows whether a call is still pending and cancellable (as complete operations cannot be cancelled). In fact, it makes no sense trying to cancel a call if you don't care about when it completes. - get rid of PENDING_CALL_DUMMY. The dummy callback allows cancellation any number of times. We want to catch wrong usage by asserting that an operation is only cancelled once. - nm_firewall_manager_cancel_call() doesn't need the manager argument. Either the call-id is valid (and has a valid pointer to the manager), or there is a bug and it is a dangling pointer.
2015-09-23 17:18:44 +02:00
NULL,
NULL,
core: use singleton nm_firewall_manager_get() throughout without taking additional ref No need to keep references of the singleton and take an additional ref when accessing nm_firewall_manager_get(). Especially, since the firewall manager instance was nowhere passed in from externally, it doesn't even sense for some vague testing purporse. Not to mention, that there are no tests that actually inject a firewall manager stub. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-02 15:19:58 +02:00
NULL);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
}
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
priv->fw_state = FIREWALL_STATE_UNMANAGED;
g_clear_object (&priv->fw_mgr);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
queued_state_clear (self);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
device: refactor the ip cleanup Split it up and move upwards. It will be useful for runtime reconfig of IPv4 configuration.
2015-11-21 12:28:09 +01:00
_cleanup_ip4_pre (self, cleanup_type);
_cleanup_ip6_pre (self, cleanup_type);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
}
static void
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
_cleanup_generic_post (NMDevice *self, CleanupType cleanup_type)
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device/trivial: rename private field in NMDevicePrivate Rename "default_route.v4_configure_first_time" to "v4_commit_first_time". For one, the name "commit" matches better to the @commit variable in ip4_config_merge_and_apply() and ip6_config_merge_and_apply(). Then, we don't need this information only for default-routes, so move the variable out of the @default_route struct.
2015-07-22 11:40:35 +02:00
priv->v4_commit_first_time = TRUE;
priv->v6_commit_first_time = TRUE;
policy: add manager for default routes and support multiple default routes Up to now, NMPolicy would iterate over all devices to find the "best" device and assign the default route to that device. A better approach is to add a default route to *all* devices that are never-default=no. The relative priority is choosen according to the route metrics. If two devices receive the same metric, we want to prefer the device that activates first. That way, the default route sticks to the same device until a better device activates or the device deactivates. Hence, the order of activation is imporant in this case (as it is already now). Also, if several devices have identical metrics, increment their metrics so that every metric is unique. This makes the routing deterministic according to what we choose as best device. A special case is assumed devices. In this case we cannot adjust the metric in face of equal metrics. Add a new singleton class NMDefaultRouteManager that has a list of all devices and their default routes. The manager will order the devices by their priority and configure the routes using platform. Also update the metric for VPN connections. Later we will track VPN routes also via NMDefaultRouteManager. For now, fix the VPN metric because otherwise VPNs would always get metric 1024 (which is usually much larger then the device metrics). https://bugzilla.gnome.org/show_bug.cgi?id=735512 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-29 00:03:47 +02:00
all: rework configuring route table support by adding "route-table" setting We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
2017-09-28 08:40:41 +02:00
priv->v4_route_table_initalized = FALSE;
priv->v6_route_table_initalized = FALSE;
core: rework tracking of gateway/default-route in ip-config Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-04 15:21:21 +02:00
priv->default_route_metric_penalty_ip4_has = FALSE;
priv->default_route_metric_penalty_ip6_has = FALSE;
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
priv->linklocal6_dad_counter = 0;
Revert "manager: don't remove the device before policy learns of ip config change" This doesn't unexport the connection on disconnect (as opposed to device removal). This reverts commit f72816bf108cf3fa52ae267e3622a1f19db28b21.
2016-04-04 12:52:56 +02:00
/* Clean up IP configs; this does not actually deconfigure the
* interface; the caller must flush routes and addresses explicitly.
*/
core: track IPv4 device routes in NMIP4Config For IPv6, we create device routes when processing the RA and add it to NMIP6Config like any other route. For IPv4 we didn't do that. Instead we created the list of device routes during nm_ip4_config_commit() and passed it to nm_platform_ip_route_sync().
2017-09-12 13:45:53 +02:00
nm_device_set_ip4_config (self, NULL, TRUE, NULL);
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
nm_device_set_ip6_config (self, NULL, TRUE);
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
g_clear_object (&priv->proxy_config);
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
g_clear_object (&priv->con_ip4_config);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
g_clear_object (&priv->dev_ip4_config);
g_clear_object (&priv->ext_ip4_config);
wwan: split out WWAN IP4Config from device config We want to set the WWAN config last, to ensure that the configuration we use overwrites anything that pppd might have set, becuase it touches some stuff itself. That means we have to keep the WWAN config separate, since dev_ip4_config is used for DHCP and IPv4LL, which we always set first to ensure they these don't overwrite external, administrator added config (eg, priv->ext_ip4_config). This also synchronizes the IPv4 config path with the upcoming IPv6 config path.
2014-07-15 17:16:56 -05:00
g_clear_object (&priv->wwan_ip4_config);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
g_clear_object (&priv->ip4_config);
device: better accept external IP changes When receiving IP changes via platform event, remove all missing addresses and routes from our internal configurations (such as wwan, vpn, dhcp). The effect is that on the next commit, those addresses and routes will not be re-added as they were explicitly removed by the user. However on a new DHCP lease or similar events, the addresses will be added anew. Another important improvement is that the NMIPxConfig of the active device reflects when addresses or routes get removed externally. Before we would continue to expose those entires although they were not actually configured on the device. https://bugzilla.gnome.org/show_bug.cgi?id=740443
2014-11-21 13:13:48 +01:00
g_clear_object (&priv->con_ip6_config);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
g_clear_object (&priv->ac_ip6_config);
g_clear_object (&priv->ext_ip6_config);
device: add ext_ip6_config_captured to remember the last-read platform configuration ext_ip6_config gets modified to only contain items that are configured externally, not by internal choice.
2016-01-30 21:37:22 +01:00
g_clear_object (&priv->ext_ip6_config_captured);
wwan: add infrastructure for IPv6 config results
2013-10-15 21:03:42 -05:00
g_clear_object (&priv->wwan_ip6_config);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
g_clear_object (&priv->ip6_config);
device: wait for termination of IPv6 DAD before proceeding to IP_CHECK Currently NM proceeds with the activation of a device just after the IPv6 configuration is applied. Server applications will bind to IPv6 addresses as soon as NM signals the presence of network connectivity, but since the addresses are still tentative the bind will fail. There are a couple of solutions to this. Linux kernel supports "optimistic DAD", which is a modification of Neighbor Discovery and SLAAC processes that allows addresses to be used (under certain contraints) while kernel is performing DAD on them. However it is not feasible to let NM enable optimistic DAD for the devices it controls for the following reasons: - it is not guaranteed to be always available since it can be turned off at compile time - RFC 4429 states that it should not be used for manually entered addresses - it works only with autoconf addresses generated by kernel Therefore, use a different approach and handle this in NM by waiting that the kernel completes DAD before continuing activation. We build a list of addresses that are tentative just after the new configuration is applied and then we asynchronously wait a platform address-change event where all NM-configured addresses become non-tentative. A similar solution has been adopted also by other network managing tools: https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f https://github.com/systemd/systemd/commit/8012cd391932d58b44332df106d426a360faf0a6 https://bugzilla.redhat.com/show_bug.cgi?id=1243958
2016-03-14 18:37:57 +01:00
g_clear_object (&priv->dad6_ip6_config);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC) Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
2017-09-13 16:45:22 +02:00
g_clear_pointer (&priv->rt6_temporary_not_available, g_hash_table_unref);
nm_clear_g_source (&priv->rt6_temporary_not_available_id);
device: allow multiple vpn IP configurations
2015-08-19 23:07:13 +02:00
g_slist_free_full (priv->vpn4_configs, g_object_unref);
priv->vpn4_configs = NULL;
g_slist_free_full (priv->vpn6_configs, g_object_unref);
priv->vpn6_configs = NULL;
device: disable delegating prefixes to the device when the IPv6 config is removed Fixes a crash where the default DNS domain to be announced together with the prefixes to be delegated is updated at the same time the device is being unrealized. https://bugzilla.redhat.com/show_bug.cgi?id=1425818
2017-04-27 15:37:14 +02:00
/* We no longer accept the delegations. nm_device_set_ip6_config(NULL)
* above disables them. */
nm_assert (priv->needs_ip6_subnet == FALSE);
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
if (priv->act_request) {
nm_active_connection_set_default (NM_ACTIVE_CONNECTION (priv->act_request), FALSE);
priv->master_ready_handled = FALSE;
nm_clear_g_signal_handler (priv->act_request, &priv->master_ready_id);
act_request_set (self, NULL);
}
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
/* Clear legacy IPv4 address property */
if (priv->ip4_address) {
priv->ip4_address = 0;
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IP4_ADDRESS);
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
}
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
if (cleanup_type == CLEANUP_TYPE_DECONFIGURE) {
core: consolidate generic device cleanup tasks dispose() and nm_device_cleanup() both do common tasks; consolidate these common tasks in one place and call when appropriate.
2014-05-22 14:51:55 -05:00
/* Check if the device was deactivated, and if so, delete_link.
* Don't call delete_link synchronously because we are currently
* handling a state change -- which is not reentrant. */
delete_on_deactivate_check_and_schedule (self, nm_device_get_ip_ifindex (self));
}
/* ip_iface should be cleared after flushing all routes and addreses, since
* those are identified by ip_iface, not by iface (which might be a tty
* or ATM device).
*/
nm_device_set_ip_iface (self, NULL);
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/*
* nm_device_cleanup
*
* Remove a device's routing table entries and IP addresses.
*
*/
static void
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
nm_device_cleanup (NMDevice *self, NMDeviceStateReason reason, CleanupType cleanup_type)
core/libnm-glib: implement better missing firmware support (rh #594578) Track missing firmware and ensure the device can't be used when firmware is missing. Add a property for missing firmware so that clients can do something intelligent with this information.
2010-05-25 10:52:25 -07:00
{
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
NMDevicePrivate *priv;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
int ifindex;
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
g_return_if_fail (NM_IS_DEVICE (self));
core/libnm-glib: implement better missing firmware support (rh #594578) Track missing firmware and ensure the device can't be used when firmware is missing. Add a property for missing firmware so that clients can do something intelligent with this information.
2010-05-25 10:52:25 -07:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
if (reason == NM_DEVICE_STATE_REASON_NOW_MANAGED)
core/logging: reduce info logging messages for devices https://bugzilla.redhat.com/show_bug.cgi?id=1212196
2015-04-17 13:47:10 +02:00
_LOGD (LOGD_DEVICE, "preparing device");
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
else
core/logging: reduce info logging messages for devices https://bugzilla.redhat.com/show_bug.cgi?id=1212196
2015-04-17 13:47:10 +02:00
_LOGD (LOGD_DEVICE, "deactivating device (reason '%s') [%d]", reason_to_string (reason), reason);
core/libnm-glib: implement better missing firmware support (rh #594578) Track missing firmware and ensure the device can't be used when firmware is missing. Add a property for missing firmware so that clients can do something intelligent with this information.
2010-05-25 10:52:25 -07:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Save whether or not we tried IPv6 for later */
priv = NM_DEVICE_GET_PRIVATE (self);
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
_cleanup_generic_pre (self, cleanup_type);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Turn off kernel IPv6 */
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
if (cleanup_type == CLEANUP_TYPE_DECONFIGURE) {
device: do not touch sysctls after the device was removed Paths to sysctls don't use ifindex and device names can be reused. If someone removes a device and quickly creates a device with the same name, chances are we're cleaning up the device that was just added. Sadly, it seems there's no better API than sysctl-- neither netlink nor procfs symlinks with ifindex or anything like that.
2015-03-16 18:19:05 +01:00
set_disable_ipv6 (self, "1");
nm_device_ipv6_sysctl_set (self, "accept_ra", "0");
nm_device_ipv6_sysctl_set (self, "use_tempaddr", "0");
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Call device type-specific deactivation */
if (NM_DEVICE_GET_CLASS (self)->deactivate)
NM_DEVICE_GET_CLASS (self)->deactivate (self);
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
ifindex = nm_device_get_ip_ifindex (self);
device: leave device up when setting it as unmanaged by user Before, setting a device to unmanaged causes it to go down and clear the interface state. It may be useful to instruct NetworkManager not to touch the device anymore but leave the current state up. Changing behavior for nmcli device set "$DEV" managed no To get the previous behavior, one has to first disconnect the interface via nmcli device disconnect "$DEV" nmcli device set "$DEV" managed no Note that non-permanent addresses like from DHCP will eventually time out because NetworkManager stops the DHCP client. When instructing NetworkManager to let go of the device, you have to take it over in any way you see fit. https://bugzilla.redhat.com/show_bug.cgi?id=1371433
2017-04-18 14:46:27 +02:00
if (cleanup_type == CLEANUP_TYPE_DECONFIGURE) {
device: don't flush addresses when unmanaging assumed devices When a assumed software device is brought down externally, it becomes UNMANAGED_EXTERNAL_DOWN and its state goes from ACTIVATED directly to UNMANAGED. In such case, we shouldn't flush the IP configuration (addresses and routes) present on the device. To fix this, clean up the device with CLEANUP_TYPE_KEEP and modify nm_device_cleanup() not to flush addresses and devices with such flag. https://bugzilla.redhat.com/show_bug.cgi?id=1363995 (cherry picked from commit 45cd3302dc2485bcf773c3e7144632a03a4d5d4e)
2016-08-09 15:34:34 +02:00
/* master: release slaves */
nm_device_master_release_slaves (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: don't flush addresses when unmanaging assumed devices When a assumed software device is brought down externally, it becomes UNMANAGED_EXTERNAL_DOWN and its state goes from ACTIVATED directly to UNMANAGED. In such case, we shouldn't flush the IP configuration (addresses and routes) present on the device. To fix this, clean up the device with CLEANUP_TYPE_KEEP and modify nm_device_cleanup() not to flush addresses and devices with such flag. https://bugzilla.redhat.com/show_bug.cgi?id=1363995 (cherry picked from commit 45cd3302dc2485bcf773c3e7144632a03a4d5d4e)
2016-08-09 15:34:34 +02:00
/* Take out any entries in the routing table and any IP address the device had. */
if (ifindex > 0) {
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
NMPlatform *platform = nm_device_get_platform (self);
nm_platform_ip_route_flush (platform, AF_UNSPEC, ifindex);
nm_platform_ip_address_flush (platform, AF_UNSPEC, ifindex);
device: don't flush addresses when unmanaging assumed devices When a assumed software device is brought down externally, it becomes UNMANAGED_EXTERNAL_DOWN and its state goes from ACTIVATED directly to UNMANAGED. In such case, we shouldn't flush the IP configuration (addresses and routes) present on the device. To fix this, clean up the device with CLEANUP_TYPE_KEEP and modify nm_device_cleanup() not to flush addresses and devices with such flag. https://bugzilla.redhat.com/show_bug.cgi?id=1363995 (cherry picked from commit 45cd3302dc2485bcf773c3e7144632a03a4d5d4e)
2016-08-09 15:34:34 +02:00
}
core: emit textual descriptions of device state changes Throw users a bone about what's happening.
2011-05-03 11:57:26 -05:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
platform: add non-exclusive routes and drop route-manager Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
2017-08-14 14:18:53 +02:00
if (ifindex > 0)
nm_platform_ip4_dev_route_blacklist_set (nm_device_get_platform (self), ifindex, NULL);
device: release removed devices from master on cleanup On cleanup, unconditionally release a device from its master if the link is missing or it doesn't have a master, otherwise the master would later try to release the slave, hitting the following assertion: "nm_platform_link_release: assertion 'slave > 0' failed" #0 g_logv #1 g_log #2 g_return_if_fail_warning #3 nm_platform_link_release #4 release_slave #5 nm_device_master_release_one_slave #6 slave_state_changed #7 ffi_call_unix64 #8 ffi_call #9 g_cclosure_marshal_generic #10 g_closure_invoke #11 signal_emit_unlocked_R #12 g_signal_emit_valist #14 _set_state_full #15 nm_device_state_changed #16 nm_device_unrealize #17 _platform_link_cb_idle #18 g_main_context_dispatch #19 g_main_context_dispatch #20 g_main_context_iterate #21 g_main_loop_run #22 main Fixes: 9e8218f99a2d5a7020703e0fbac1c7c0983930db https://bugzilla.redhat.com/show_bug.cgi?id=1448907
2017-05-08 21:22:00 +02:00
/* slave: mark no longer enslaved */
if ( priv->master
&& nm_platform_link_get_master (nm_device_get_platform (self), priv->ifindex) <= 0)
nm_device_master_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
if (priv->lldp_listener)
nm_lldp_listener_stop (priv->lldp_listener);
core: update device 'metered' property on connection state change The metered property of a NMDevice that reaches the activated state is copied from the active connection and if its value is 'unknown' some heuristics are used to guess the actual value. When the connection is torn down the metered property is reset to 'unknown'.
2015-04-30 14:18:14 +02:00
nm_device_update_metered (self);
device/wifi: properly reset the initial hardware address on shutdown During shutdown, we unmanage Wi-Fi devices, and during NMDevice:deactivate() we would reset to initial MAC address. However, NMDeviceWifi:deactivate() would reset it again to the scanning one. Fix that to properly restore the initial MAC address on the device when NetworkManager exits. Fixes: 4b2e375b3393ca4ebb1069279e919cd5fc9fd2ee
2016-06-30 11:42:28 +02:00
/* during device cleanup, we want to reset the MAC address of the device
* to the initial state.
*
* We certainly want to do that when reaching the UNMANAGED state... */
if (nm_device_get_state (self) <= NM_DEVICE_STATE_UNMANAGED)
nm_device_hw_addr_reset (self, "unmanage");
else {
/* for other device states (UNAVAILABLE, DISCONNECTED), allow the
* device to overwrite the reset behavior, so that Wi-Fi can set
* a randomized MAC address used during scanning. */
NM_DEVICE_GET_CLASS (self)->deactivate_reset_hw_addr (self);
}
device: set a per-device default MTU on activation In absence of an explicit MTU (either via user configuration, PPP or DHCP), set a default MTU on activation that depends on the device type. We only want to do that on the very first call to _commit_mtu(). Later calls (for example in response to new DHCP leases) skip over this step. This means, on activation the MTU will always be reset to a sensible value instead of preserving whatever was left from a previous configuration. This does not cover setting the MTU from the VPN plugin :(
2017-01-16 12:18:51 +01:00
priv->mtu_initialized = FALSE;
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
if (priv->mtu_initial || priv->ip6_mtu_initial) {
ifindex = nm_device_get_ip_ifindex (self);
if ( ifindex > 0
&& cleanup_type == CLEANUP_TYPE_DECONFIGURE) {
_LOGT (LOGD_DEVICE, "mtu: reset device-mtu: %u, ipv6-mtu: %u, ifindex: %d",
(guint) priv->mtu_initial, (guint) priv->ip6_mtu_initial, ifindex);
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
if (priv->mtu_initial) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_set_mtu (nm_device_get_platform (self), ifindex, priv->mtu_initial);
device: extend wait time for carrier after MTU change Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
2017-09-02 17:26:53 +02:00
priv->carrier_wait_until_ms = nm_utils_get_monotonic_timestamp_ms () + CARRIER_WAIT_TIME_AFTER_MTU_MS;
}
device: reset previous MTU when device disconnects When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set during activation. That means, the effective MTU depends on the previous MTU configuration of the device. Which in turn, depends on the previously active connection, as we don't reset the MTU on deactivation. Restore the previous MTU on deactivation iff NetworkManager changed the MTU during device activation.
2017-01-16 10:20:26 +01:00
if (priv->ip6_mtu_initial) {
char sbuf[64];
nm_device_ipv6_sysctl_set (self, "mtu",
nm_sprintf_buf (sbuf, "%u", (unsigned) priv->ip6_mtu_initial));
}
}
priv->mtu_initial = 0;
priv->ip6_mtu_initial = 0;
}
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
_cleanup_generic_post (self, cleanup_type);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
device/wifi: properly reset the initial hardware address on shutdown During shutdown, we unmanage Wi-Fi devices, and during NMDevice:deactivate() we would reset to initial MAC address. However, NMDeviceWifi:deactivate() would reset it again to the scanning one. Fix that to properly restore the initial MAC address on the device when NetworkManager exits. Fixes: 4b2e375b3393ca4ebb1069279e919cd5fc9fd2ee
2016-06-30 11:42:28 +02:00
static void
deactivate_reset_hw_addr (NMDevice *self)
{
nm_device_hw_addr_reset (self, "deactivate");
}
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
static char *
find_dhcp4_address (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
const NMPlatformIP4Address *a;
NMDedupMultiIter ipconf_iter;
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
if (!priv->ip4_config)
return NULL;
core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex Reasons: - it adds an O(1) lookup index for accessing NMIPxConfig's addresses. Hence, operations like merge/intersect have now runtime O(n) instead of O(n^2). Arguably, we expect low numbers of addresses in general. For low numbers, the O(n^2) doesn't matter and quite likely in those cases the previous implementation was just fine -- maybe even faster. But the simple case works fine either way. It's important to scale well in the exceptional case. - the tracked objects can be shared between the various NMPI4Config, NMIP6Config instances with NMPlatform and everybody else. - the NMPObject can be treated generically, meaning it enables code to handle both IPv4 and IPv6, or addresses and routes. See for example _nm_ip_config_add_obj(). - I want core to evolve to somewhere where we don't keep copies of NMPlatformIP4Address, et al. instances. Instead they shall all be shared. I hope this will reduce memory consumption (although tracking a reference consumes some memory too). Also, it shortcuts nmp_object_equal() when comparing the same object. Calling nmp_object_equal() on the identical objects would be a common case after the hash function pre-evaluates equality.
2017-07-07 23:34:41 +02:00
nm_ip_config_iter_ip4_address_for_each (&ipconf_iter, priv->ip4_config, &a) {
core/trivial: rename "source" field of addresses and routes The "source" field of NMPlatformIPRoute (now "rt_source") maps to the protocol field of the route. The source of NMPlatformIPAddress (now "addr_source") has no direct equivalent in the kernel. As their use is different, they should have different names. Also, the name "source" is used all over the place. Hence give the fields a more distinct name.
2016-04-11 13:09:52 +02:00
if (a->addr_source == NM_IP_CONFIG_SOURCE_DHCP)
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
return g_strdup (nm_utils_inet4_ntop (a->address, NULL));
}
return NULL;
}
void
nm_device_spawn_iface_helper (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
iface-helper: disambiguate route priority for IPv4 and IPv6 https://bugzilla.gnome.org/show_bug.cgi?id=740780
2014-11-26 21:20:23 +01:00
gboolean configured = FALSE;
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
NMConnection *connection;
GError *error = NULL;
const char *method;
GPtrArray *argv;
gs_free char *dhcp4_address = NULL;
logging: make use of journal configurable
2015-07-08 19:34:34 +02:00
char *logging_backend;
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
NMUtilsStableType stable_type;
const char *stable_id;
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
if (priv->state != NM_DEVICE_STATE_ACTIVATED)
return;
if (!nm_device_can_assume_connections (self))
return;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_applied_connection (self);
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
g_assert (connection);
argv = g_ptr_array_sized_new (10);
g_ptr_array_set_free_func (argv, g_free);
g_ptr_array_add (argv, g_strdup (LIBEXECDIR "/nm-iface-helper"));
g_ptr_array_add (argv, g_strdup ("--ifname"));
g_ptr_array_add (argv, g_strdup (nm_device_get_ip_iface (self)));
g_ptr_array_add (argv, g_strdup ("--uuid"));
g_ptr_array_add (argv, g_strdup (nm_connection_get_uuid (connection)));
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
stable_id = _get_stable_id (self, connection, &stable_type);
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
if (stable_id && stable_type != NM_UTILS_STABLE_TYPE_UUID) {
g_ptr_array_add (argv, g_strdup ("--stable-id"));
g_ptr_array_add (argv, g_strdup_printf ("%d %s", (int) stable_type, stable_id));
}
logging: make use of journal configurable
2015-07-08 19:34:34 +02:00
logging_backend = nm_config_get_is_debug (nm_config_get ())
? g_strdup ("debug")
: nm_config_data_get_value (NM_CONFIG_GET_DATA_ORIG,
NM_CONFIG_KEYFILE_GROUP_LOGGING,
NM_CONFIG_KEYFILE_KEY_LOGGING_BACKEND,
NM_CONFIG_GET_VALUE_STRIP | NM_CONFIG_GET_VALUE_NO_EMPTY);
if (logging_backend) {
g_ptr_array_add (argv, g_strdup ("--logging-backend"));
g_ptr_array_add (argv, logging_backend);
}
iface-helper: pass on the logging level to nm-iface-helper
2016-10-05 15:40:12 +02:00
g_ptr_array_add (argv, g_strdup ("--log-level"));
g_ptr_array_add (argv, g_strdup (nm_logging_level_to_string ()));
g_ptr_array_add (argv, g_strdup ("--log-domains"));
g_ptr_array_add (argv, g_strdup (nm_logging_domains_to_string ()));
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
dhcp4_address = find_dhcp4_address (self);
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP4_CONFIG);
iface-helper: enabled dhcp4/slaac according to IP method If at the moment when spawning nm-iface-helper dhcp4/slaac did not yet complete, we would not enable it. That is wrong. If the connection indicates to use dhcp4/slaac, it should be used by nm-iface-helper without considering the current state on the device. https://bugzilla.redhat.com/show_bug.cgi?id=1260243
2015-09-11 17:07:23 +02:00
if (g_strcmp0 (method, NM_SETTING_IP4_CONFIG_METHOD_AUTO) == 0) {
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
NMSettingIPConfig *s_ip4;
s_ip4 = nm_connection_get_setting_ip4_config (connection);
g_assert (s_ip4);
iface-helper: disambiguate route priority for IPv4 and IPv6 https://bugzilla.gnome.org/show_bug.cgi?id=740780
2014-11-26 21:20:23 +01:00
g_ptr_array_add (argv, g_strdup ("--priority4"));
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
g_ptr_array_add (argv, g_strdup_printf ("%u", nm_device_get_route_metric (self, AF_INET)));
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
g_ptr_array_add (argv, g_strdup ("--dhcp4"));
g_ptr_array_add (argv, g_strdup (dhcp4_address));
if (nm_setting_ip_config_get_may_fail (s_ip4) == FALSE)
g_ptr_array_add (argv, g_strdup ("--dhcp4-required"));
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
if (priv->dhcp4.client) {
dhcp: simplify how hostname and FQDN are passed down to backends Since they are mutually exclusive, pass a string and a boolean to indicate whether we want to use the hostname or the FQDN option.
2017-04-26 11:49:30 +02:00
const char *hostname;
iface-helper: enabled dhcp4/slaac according to IP method If at the moment when spawning nm-iface-helper dhcp4/slaac did not yet complete, we would not enable it. That is wrong. If the connection indicates to use dhcp4/slaac, it should be used by nm-iface-helper without considering the current state on the device. https://bugzilla.redhat.com/show_bug.cgi?id=1260243
2015-09-11 17:07:23 +02:00
GBytes *client_id;
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
client_id = nm_dhcp_client_get_client_id (priv->dhcp4.client);
iface-helper: enabled dhcp4/slaac according to IP method If at the moment when spawning nm-iface-helper dhcp4/slaac did not yet complete, we would not enable it. That is wrong. If the connection indicates to use dhcp4/slaac, it should be used by nm-iface-helper without considering the current state on the device. https://bugzilla.redhat.com/show_bug.cgi?id=1260243
2015-09-11 17:07:23 +02:00
if (client_id) {
g_ptr_array_add (argv, g_strdup ("--dhcp4-clientid"));
all: reuse _nm_utils_hwaddr_ntoa() for converting binary to string
2016-07-10 13:42:13 +02:00
g_ptr_array_add (argv,
_nm_utils_bin2str (g_bytes_get_data (client_id, NULL),
g_bytes_get_size (client_id),
FALSE));
iface-helper: enabled dhcp4/slaac according to IP method If at the moment when spawning nm-iface-helper dhcp4/slaac did not yet complete, we would not enable it. That is wrong. If the connection indicates to use dhcp4/slaac, it should be used by nm-iface-helper without considering the current state on the device. https://bugzilla.redhat.com/show_bug.cgi?id=1260243
2015-09-11 17:07:23 +02:00
}
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
hostname = nm_dhcp_client_get_hostname (priv->dhcp4.client);
iface-helper: enabled dhcp4/slaac according to IP method If at the moment when spawning nm-iface-helper dhcp4/slaac did not yet complete, we would not enable it. That is wrong. If the connection indicates to use dhcp4/slaac, it should be used by nm-iface-helper without considering the current state on the device. https://bugzilla.redhat.com/show_bug.cgi?id=1260243
2015-09-11 17:07:23 +02:00
if (hostname) {
dhcp: simplify how hostname and FQDN are passed down to backends Since they are mutually exclusive, pass a string and a boolean to indicate whether we want to use the hostname or the FQDN option.
2017-04-26 11:49:30 +02:00
if (nm_dhcp_client_get_use_fqdn (priv->dhcp4.client))
g_ptr_array_add (argv, g_strdup ("--dhcp4-fqdn"));
else
g_ptr_array_add (argv, g_strdup ("--dhcp4-hostname"));
iface-helper: enabled dhcp4/slaac according to IP method If at the moment when spawning nm-iface-helper dhcp4/slaac did not yet complete, we would not enable it. That is wrong. If the connection indicates to use dhcp4/slaac, it should be used by nm-iface-helper without considering the current state on the device. https://bugzilla.redhat.com/show_bug.cgi?id=1260243
2015-09-11 17:07:23 +02:00
g_ptr_array_add (argv, g_strdup (hostname));
}
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
}
configured = TRUE;
}
method = nm_utils_get_ip_config_method (connection, NM_TYPE_SETTING_IP6_CONFIG);
iface-helper: enabled dhcp4/slaac according to IP method If at the moment when spawning nm-iface-helper dhcp4/slaac did not yet complete, we would not enable it. That is wrong. If the connection indicates to use dhcp4/slaac, it should be used by nm-iface-helper without considering the current state on the device. https://bugzilla.redhat.com/show_bug.cgi?id=1260243
2015-09-11 17:07:23 +02:00
if (g_strcmp0 (method, NM_SETTING_IP6_CONFIG_METHOD_AUTO) == 0) {
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
NMSettingIPConfig *s_ip6;
NMUtilsIPv6IfaceId iid = NM_UTILS_IPV6_IFACE_ID_INIT;
s_ip6 = nm_connection_get_setting_ip6_config (connection);
g_assert (s_ip6);
iface-helper: disambiguate route priority for IPv4 and IPv6 https://bugzilla.gnome.org/show_bug.cgi?id=740780
2014-11-26 21:20:23 +01:00
g_ptr_array_add (argv, g_strdup ("--priority6"));
device/trivial: rename nm_device_get_ip_route_metric() to nm_device_get_route_metric() Brevity!
2017-09-28 17:14:24 +02:00
g_ptr_array_add (argv, g_strdup_printf ("%u", nm_device_get_route_metric (self, AF_INET6)));
iface-helper: disambiguate route priority for IPv4 and IPv6 https://bugzilla.gnome.org/show_bug.cgi?id=740780
2014-11-26 21:20:23 +01:00
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
g_ptr_array_add (argv, g_strdup ("--slaac"));
if (nm_setting_ip_config_get_may_fail (s_ip6) == FALSE)
g_ptr_array_add (argv, g_strdup ("--slaac-required"));
g_ptr_array_add (argv, g_strdup ("--slaac-tempaddr"));
rdisc: rename to ndisc We'll soon not only do the router discovery, but announce ourselves as a reouter. "Neighbor discovery" sounds to be a more appropriate name for the class than "Router discovery".
2016-10-13 11:06:25 +00:00
g_ptr_array_add (argv, g_strdup_printf ("%d", priv->ndisc_use_tempaddr));
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
device: set the iid to rdisc from connection's property ...as opposed to directly from the platform. If the token was set in platform, it was picked up when generating a connection anyway.
2016-05-11 12:19:28 +02:00
if (nm_device_get_ip_iface_identifier (self, &iid, FALSE)) {
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
g_ptr_array_add (argv, g_strdup ("--iid"));
all: reuse _nm_utils_hwaddr_ntoa() for converting binary to string
2016-07-10 13:42:13 +02:00
g_ptr_array_add (argv,
_nm_utils_bin2str (iid.id_u8,
sizeof (NMUtilsIPv6IfaceId),
FALSE));
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
}
core: add support for RFC7217 stable privacy addressing RFC7217 introduces an alternative mechanism for creating addresses during stateless IPv6 address configuration. It's supposed to create addresses whose host part stays stable in a particular network but changes when the hosts enters another network to mitigate possibility of tracking the host movement. It can be used alongside RFC 4941 privacy extensions (temporary addresses) and replaces the use of RFC 4862 interface identifiers. The address creation mode is controlld by ip6.addr_gen_mode property (ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64", defaulting to "eui-64" if unspecified. The host part of an address is computed by hashing a system-specific secret salted with various stable values that identify the connection with a secure hash algorithm: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) For NetworkManager we use these parameters: * F() SHA256 hash function. * Prefix This is a network part of the /64 address * Net_Iface We use the interface name (e.g. "eth0"). This ensures the address won't change with the change of interface hardware. * Network_ID We use the connection UUID here. This ensures the salt is different for wireless networks with a different SSID as suggested by RFC7217. * DAD_Counter A per-address counter that increases with each DAD failure. * secret_key We store the secret key in /var/lib/NetworkManager/secret_key. If it's shorter than 128 bits then it's rejected. If the file is not present we initialize it by fetching 256 pseudo-random bits from /dev/urandom on first use. Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation and may change in future. Neither parameter is currently configurable.
2015-10-03 19:44:27 +02:00
g_ptr_array_add (argv, g_strdup ("--addr-gen-mode"));
g_ptr_array_add (argv, g_strdup_printf ("%d", nm_setting_ip6_config_get_addr_gen_mode (NM_SETTING_IP6_CONFIG (s_ip6))));
iface-helper: add nm-iface-helper for dynamic configure-then-quit support When quitting, the Manager asks each device to spawn the interface helper, which persists and manages dynamic address on the interface after NetworkManager is gone. If the dynamic address cannot be maintaned, the helper quits and the interface's address may be removed when their lifetime runs out. To keep the helper as simple as possible, NetworkManager passes most of the configuration on the command-line, including some properties of the device's current state, which are necessary for the helper to maintain DHCP leases or IPv6 SLAAC addresses.
2014-10-29 09:12:18 -05:00
configured = TRUE;
}
if (configured) {
GPid pid;
g_ptr_array_add (argv, NULL);
if (nm_logging_enabled (LOGL_DEBUG, LOGD_DEVICE)) {
char *tmp;
tmp = g_strjoinv (" ", (char **) argv->pdata);
_LOGD (LOGD_DEVICE, "running '%s'", tmp);
g_free (tmp);
}
if (g_spawn_async (NULL, (char **) argv->pdata, NULL,
G_SPAWN_DO_NOT_REAP_CHILD, NULL, NULL, &pid, &error)) {
_LOGI (LOGD_DEVICE, "spawned helper PID %u", (guint) pid);
} else {
_LOGW (LOGD_DEVICE, "failed to spawn helper: %s", error->message);
g_error_free (error);
}
}
g_ptr_array_unref (argv);
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static gboolean
ip_config_valid (NMDeviceState state)
{
return (state == NM_DEVICE_STATE_UNMANAGED) ||
(state >= NM_DEVICE_STATE_IP_CHECK &&
state <= NM_DEVICE_STATE_DEACTIVATING);
core: emit textual descriptions of device state changes Throw users a bone about what's happening.
2011-05-03 11:57:26 -05:00
}
core: fix PropertiesChanged signals for IP-related properties To present a consistent API to clients, the IP-related properties are only valid when the device has finished IP configuration. But they are set before that happens, and their change notifications were emitted before the IP configuration was considered valid. Re-emit the change notifications when the device enters the IP_CHECK state (and thus has IP configuration) and also when the device deactivates to enusre clients have up-to-date IP-related property information. For the changes to has_ip_config(), the priv->ipX_state checks are not necessary since the device will have valid IP configuration when it enters the IP_CHECK state. The other checks can be consolidated into a single statement. Acked-by: Dan Winship
2013-10-09 13:55:05 -05:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
notify_ip_properties (NMDevice *self)
core: fix PropertiesChanged signals for IP-related properties To present a consistent API to clients, the IP-related properties are only valid when the device has finished IP configuration. But they are set before that happens, and their change notifications were emitted before the IP configuration was considered valid. Re-emit the change notifications when the device enters the IP_CHECK state (and thus has IP configuration) and also when the device deactivates to enusre clients have up-to-date IP-related property information. For the changes to has_ip_config(), the priv->ipX_state checks are not necessary since the device will have valid IP configuration when it enters the IP_CHECK state. The other checks can be consolidated into a single statement. Acked-by: Dan Winship
2013-10-09 13:55:05 -05:00
{
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_IP_IFACE);
_notify (self, PROP_IP4_CONFIG);
_notify (self, PROP_DHCP4_CONFIG);
_notify (self, PROP_IP6_CONFIG);
_notify (self, PROP_DHCP6_CONFIG);
core: fix PropertiesChanged signals for IP-related properties To present a consistent API to clients, the IP-related properties are only valid when the device has finished IP configuration. But they are set before that happens, and their change notifications were emitted before the IP configuration was considered valid. Re-emit the change notifications when the device enters the IP_CHECK state (and thus has IP configuration) and also when the device deactivates to enusre clients have up-to-date IP-related property information. For the changes to has_ip_config(), the priv->ipX_state checks are not necessary since the device will have valid IP configuration when it enters the IP_CHECK state. The other checks can be consolidated into a single statement. Acked-by: Dan Winship
2013-10-09 13:55:05 -05:00
}
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
static void
ip6_managed_setup (NMDevice *self)
{
set_nm_ipv6ll (self, TRUE);
set_disable_ipv6 (self, "1");
nm_device_ipv6_sysctl_set (self, "accept_ra_defrtr", "0");
nm_device_ipv6_sysctl_set (self, "accept_ra_pinfo", "0");
nm_device_ipv6_sysctl_set (self, "accept_ra_rtr_pref", "0");
nm_device_ipv6_sysctl_set (self, "use_tempaddr", "0");
device: announce the managed IPv6 configuration with ipv6.method=shared This esentially causes us to announce the prefixes of the addresses we own and the DNS configuration. Currently the only way to get the IPv6 configuration on such device is manual setting in the connection. This will change with IPv6 prefix delegation.
2016-11-03 12:15:32 +01:00
nm_device_ipv6_sysctl_set (self, "forwarding", "0");
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
}
device: new deactivate_async() method to be run during DEACTIVATING phase This method isn't run if NM is quitting; so the deactivate() method still needs to be implemented to handle sync disconnection requests.
2014-08-05 20:08:34 +02:00
static void
deactivate_async_ready (NMDevice *self,
GAsyncResult *res,
gpointer user_data)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMDeviceStateReason reason = GPOINTER_TO_UINT (user_data);
GError *error = NULL;
NM_DEVICE_GET_CLASS (self)->deactivate_async_finish (self, res, &error);
/* If operation cancelled, just return */
if ( g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED)
|| (priv->deactivating_cancellable && g_cancellable_is_cancelled (priv->deactivating_cancellable))) {
device: use _LOG() logging macros for per-device logging
2015-10-05 13:05:05 +02:00
_LOGW (LOGD_DEVICE, "Deactivation cancelled");
all: use nm_clear_g_cancellable()
2017-03-13 11:51:33 +01:00
} else {
/* In every other case, transition to the DISCONNECTED state */
device: use _LOG() logging macros for per-device logging
2015-10-05 13:05:05 +02:00
if (error) {
_LOGW (LOGD_DEVICE, "Deactivation failed: %s",
error->message);
}
device: new deactivate_async() method to be run during DEACTIVATING phase This method isn't run if NM is quitting; so the deactivate() method still needs to be implemented to handle sync disconnection requests.
2014-08-05 20:08:34 +02:00
nm_device_queue_state (self, NM_DEVICE_STATE_DISCONNECTED, reason);
}
g_clear_object (&priv->deactivating_cancellable);
g_clear_error (&error);
}
static void
deactivate_dispatcher_complete (guint call_id, gpointer user_data)
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMDeviceStateReason reason;
g_return_if_fail (call_id == priv->dispatcher.call_id);
g_return_if_fail (priv->dispatcher.post_state == NM_DEVICE_STATE_DISCONNECTED);
reason = priv->dispatcher.post_state_reason;
priv->dispatcher.call_id = 0;
priv->dispatcher.post_state = NM_DEVICE_STATE_UNKNOWN;
priv->dispatcher.post_state_reason = NM_DEVICE_STATE_REASON_NONE;
all: use nm_clear_g_cancellable()
2017-03-13 11:51:33 +01:00
if (nm_clear_g_cancellable (&priv->deactivating_cancellable))
device: new deactivate_async() method to be run during DEACTIVATING phase This method isn't run if NM is quitting; so the deactivate() method still needs to be implemented to handle sync disconnection requests.
2014-08-05 20:08:34 +02:00
g_warn_if_reached ();
if ( NM_DEVICE_GET_CLASS (self)->deactivate_async
&& NM_DEVICE_GET_CLASS (self)->deactivate_async_finish) {
priv->deactivating_cancellable = g_cancellable_new ();
NM_DEVICE_GET_CLASS (self)->deactivate_async (self,
priv->deactivating_cancellable,
(GAsyncReadyCallback) deactivate_async_ready,
GUINT_TO_POINTER (reason));
} else
nm_device_queue_state (self, NM_DEVICE_STATE_DISCONNECTED, reason);
}
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
static void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
_set_state_full (NMDevice *self,
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
NMDeviceState state,
NMDeviceStateReason reason,
gboolean quitting)
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
{
device: refactor beginning of _set_state_full() - Reorder statements, to first g_return_if_fail() and log state-change. - Also log a message when leaving _set_state_full() early due to missing firmware.
2015-09-21 16:48:50 +02:00
NMDevicePrivate *priv;
2007-03-02 Tambet Ingo <tambet@ximian.com> * libnm-glib/nm-device-802-11-wireless.c: Cache networks (bssids) list. We get signalled when it changes. * libnm-glib/nm-client.c: Cache NMState and device list, we get signalled when it changes. * libnm-glib/nm-device.c: Cache the device state property. * libnm-glib/nm-access-point.c: Cache the strength property. * src/nm-device-802-11-wireless.c: Fix wireless device scanning scheduler. The new algorithm is to start from SCAN_INTERVAL_MIN (currently defined as 0) and add a SCAN_INTERVAL_STEP (currently 20 seconds) with each successful scan until SCAN_INTERVAL_MAX (currently 120 seconds) is reached. Do not scan while the device is down, activating, or activated (in case of A/B/G cards). Remove some old dead ifdef'ed out code that used to configure wireless devices, it's all done through supplicant now. * src/supplicant-manager/nm-supplicant-interface.c: Fix the reference counting issues with pending calls which caused leaks and crashes when interface was removed (now that the interface actually gets removed). * src/nm-call-store.c: Make a copy of data before running a foreach with user callback on it - The most common usage pattern is to cancel (and thus remove) all pending calls with foreach which would modify the hash table we're iterating over. * src/nm-manager.c: When a device is added, make sure it is "up". When it's removed or disabled due to disabling wireless or networking, bring it down. * include/NetworkManager.h: Add new device state NM_DEVICE_STATE_DOWN. * src/nm-device-802-11-wireless.c: * src/nm-device-802-3-ethernet.c: * src/nm-device.c: - Remove "init" virtual function, all gobjects have a place for that already (constructor). - Replace "start" virtual function with "bring_up", devices can be brought up and down more than just on startup now. - Add "is_up" virtual function. - Implement one way to bring a device down instead of previous 4 different ways, each of witch did something different. * src/NetworkManagerUtils.c (nm_dev_sock_open): This doesn't need an NMDevice, all it needs is the device interface. Get rid of NMData.dev_list (3 members to go). Get rif of NMData in a lot of places. * gnome/libnm_glib/libnm_glib.c: Make it compile again. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2395 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-03-02 09:30:48 +00:00
NMDeviceState old_state;
2008-04-27 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-dispatcher-action.c callouts/nm-dispatcher-action.h callouts/nm-dispatcher.conf callouts/nm-dispatcher.xml callouts/org.freedesktop.nm_dispatcher.service - Re-implement the dispatcher as a system-bus activated service that NM calls on-demand, rather than an always running daemon * src/Makefile.am - Add callouts dir to includes to pick up dispatcher defines * src/nm-device.c - (nm_device_state_changed): call dispatcher on device activated/ deactivated * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_set_vpn_state): call dispatcher when VPN connections go up and down * src/NetworkManagerUtils.c src/NetworkManagerUtils.h - (nm_utils_call_dispatcher): helper to call dispatcher git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3607 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-27 14:30:06 +00:00
NMActRequest *req;
2008-08-18 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h introspection/nm-device.xml - Add a "missing firmware" device state reason * src/NetworkManagerSystem.c src/NetworkManagerSystem.h - (nm_system_device_set_up_down): add a no_firmware argument - (nm_system_device_set_up_down_with_iface): if the result of setting IFF_UP is ENOENT, that almost always means missing firmware * src/backends/NetworkManagerGeneric.c src/nm-device-ethernet.c src/nm-device-private.h src/nm-device-wifi.c src/nm-device.c src/nm-device.h src/nm-hso-gsm-device.c src/vpn-manager/nm-vpn-connection.c - Pass no_firmware along; check it where appropriate git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3983 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-08-18 18:29:47 +00:00
gboolean no_firmware = FALSE;
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
NMSettingsConnection *connection;
2007-03-02 Tambet Ingo <tambet@ximian.com> * libnm-glib/nm-device-802-11-wireless.c: Cache networks (bssids) list. We get signalled when it changes. * libnm-glib/nm-client.c: Cache NMState and device list, we get signalled when it changes. * libnm-glib/nm-device.c: Cache the device state property. * libnm-glib/nm-access-point.c: Cache the strength property. * src/nm-device-802-11-wireless.c: Fix wireless device scanning scheduler. The new algorithm is to start from SCAN_INTERVAL_MIN (currently defined as 0) and add a SCAN_INTERVAL_STEP (currently 20 seconds) with each successful scan until SCAN_INTERVAL_MAX (currently 120 seconds) is reached. Do not scan while the device is down, activating, or activated (in case of A/B/G cards). Remove some old dead ifdef'ed out code that used to configure wireless devices, it's all done through supplicant now. * src/supplicant-manager/nm-supplicant-interface.c: Fix the reference counting issues with pending calls which caused leaks and crashes when interface was removed (now that the interface actually gets removed). * src/nm-call-store.c: Make a copy of data before running a foreach with user callback on it - The most common usage pattern is to cancel (and thus remove) all pending calls with foreach which would modify the hash table we're iterating over. * src/nm-manager.c: When a device is added, make sure it is "up". When it's removed or disabled due to disabling wireless or networking, bring it down. * include/NetworkManager.h: Add new device state NM_DEVICE_STATE_DOWN. * src/nm-device-802-11-wireless.c: * src/nm-device-802-3-ethernet.c: * src/nm-device.c: - Remove "init" virtual function, all gobjects have a place for that already (constructor). - Replace "start" virtual function with "bring_up", devices can be brought up and down more than just on startup now. - Add "is_up" virtual function. - Implement one way to bring a device down instead of previous 4 different ways, each of witch did something different. * src/NetworkManagerUtils.c (nm_dev_sock_open): This doesn't need an NMDevice, all it needs is the device interface. Get rid of NMData.dev_list (3 members to go). Get rif of NMData in a lot of places. * gnome/libnm_glib/libnm_glib.c: Make it compile again. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2395 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-03-02 09:30:48 +00:00
device: refactor beginning of _set_state_full() - Reorder statements, to first g_return_if_fail() and log state-change. - Also log a message when leaving _set_state_full() early due to missing firmware.
2015-09-21 16:48:50 +02:00
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
trivial: warn if we ever re-enter nm_device_state_changed() Motivated by ba48be3a344b64dfb808cb6f3e545829d9884bee.
2012-10-06 12:37:34 -05:00
/* Track re-entry */
devices: fix recursive-state-change check nm_device_state_changed() had a check to make sure it wasn't entered recursively (which had been a source of bugs in the past), but it was global rather than per-device, so it caused errors when VLANs changed state in response to their parent device changing state. Fix that. https://bugzilla.gnome.org/show_bug.cgi?id=698619
2013-05-20 16:15:37 -03:00
g_warn_if_fail (priv->in_state_changed == FALSE);
trivial: warn if we ever re-enter nm_device_state_changed() Motivated by ba48be3a344b64dfb808cb6f3e545829d9884bee.
2012-10-06 12:37:34 -05:00
device: refactor beginning of _set_state_full() - Reorder statements, to first g_return_if_fail() and log state-change. - Also log a message when leaving _set_state_full() early due to missing firmware.
2015-09-21 16:48:50 +02:00
old_state = priv->state;
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
core: better missing firmware handling when firmware appears (rh #609587) Monitor the kernel firmware directory (set at configure-time with --with-kernel-firmware-dir=<path>) for changes, and if there are any, try bringing up devices that are missing firmware.
2010-07-01 10:32:11 -07:00
/* Do nothing if state isn't changing, but as a special case allow
* re-setting UNAVAILABLE if the device is missing firmware so that we
* can retry device initialization.
*/
if ( (priv->state == state)
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
&& ( state != NM_DEVICE_STATE_UNAVAILABLE
|| !priv->firmware_missing)) {
device: reword logging line about device's state change The line device (wlan0): state change: ip-config -> ip-check (reason none, internal state managed) prints the sys-iface-state, which is at other places logged with device[0x55914506ed70] (wlan0): sys-iface-state: external -> managed For consistency, name the same parameter the same.
2017-10-06 11:45:38 +02:00
_LOGD (LOGD_DEVICE, "state change: %s -> %s (reason '%s', sys-iface-state: '%s'%s)",
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (old_state),
nm_device_state_to_str (state),
device: refactor beginning of _set_state_full() - Reorder statements, to first g_return_if_fail() and log state-change. - Also log a message when leaving _set_state_full() early due to missing firmware.
2015-09-21 16:48:50 +02:00
reason_to_string (reason),
device: add the internal interface state to the state change log message
2017-05-19 15:35:29 +02:00
_sys_iface_state_to_str (priv->sys_iface_state),
priv->firmware_missing ? ", missing firmware" : "");
Notify on device state change git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3489 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-24 02:56:25 +00:00
return;
device: clear nm_device_state_changed() re-entry check on early exit
2012-10-10 17:30:46 +02:00
}
Notify on device state change git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3489 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-03-24 02:56:25 +00:00
device: reword logging line about device's state change The line device (wlan0): state change: ip-config -> ip-check (reason none, internal state managed) prints the sys-iface-state, which is at other places logged with device[0x55914506ed70] (wlan0): sys-iface-state: external -> managed For consistency, name the same parameter the same.
2017-10-06 11:45:38 +02:00
_LOGI (LOGD_DEVICE, "state change: %s -> %s (reason '%s', sys-iface-state: '%s')",
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (old_state),
nm_device_state_to_str (state),
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
reason_to_string (reason),
device: add the internal interface state to the state change log message
2017-05-19 15:35:29 +02:00
_sys_iface_state_to_str (priv->sys_iface_state));
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
device: refactor beginning of _set_state_full() - Reorder statements, to first g_return_if_fail() and log state-change. - Also log a message when leaving _set_state_full() early due to missing firmware.
2015-09-21 16:48:50 +02:00
priv->in_state_changed = TRUE;
priv->state = state;
priv->state_reason = reason;
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
queued_state_clear (self);
2007-06-13 Tambet Ingo <tambet@ximian.com> * src/nm-device.c (nm_device_state_changed): Emit the signal before handling it because the handling code will cause the next state change and signal listeners get the signals in wrong order. * src/NetworkManagerPolicy.c (nm_policy_device_change_check): Get the "old_dev" correctly in case of pending activation. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2593 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-06-13 11:58:25 +00:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
dispatcher_cleanup (self);
device: new deactivate_async() method to be run during DEACTIVATING phase This method isn't run if NM is quitting; so the deactivate() method still needs to be implemented to handle sync disconnection requests.
2014-08-05 20:08:34 +02:00
if (priv->deactivating_cancellable)
g_cancellable_cancel (priv->deactivating_cancellable);
core: implement PRE_DOWN dispatcher actions (bgo #387832) https://bugzilla.gnome.org/show_bug.cgi?id=387832
2014-05-20 17:10:42 -05:00
2008-04-27 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-dispatcher-action.c callouts/nm-dispatcher-action.h callouts/nm-dispatcher.conf callouts/nm-dispatcher.xml callouts/org.freedesktop.nm_dispatcher.service - Re-implement the dispatcher as a system-bus activated service that NM calls on-demand, rather than an always running daemon * src/Makefile.am - Add callouts dir to includes to pick up dispatcher defines * src/nm-device.c - (nm_device_state_changed): call dispatcher on device activated/ deactivated * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_set_vpn_state): call dispatcher when VPN connections go up and down * src/NetworkManagerUtils.c src/NetworkManagerUtils.h - (nm_utils_call_dispatcher): helper to call dispatcher git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3607 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-27 14:30:06 +00:00
/* Cache the activation request for the dispatcher */
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
req = nm_g_object_ref (priv->act_request);
2008-04-27 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-dispatcher-action.c callouts/nm-dispatcher-action.h callouts/nm-dispatcher.conf callouts/nm-dispatcher.xml callouts/org.freedesktop.nm_dispatcher.service - Re-implement the dispatcher as a system-bus activated service that NM calls on-demand, rather than an always running daemon * src/Makefile.am - Add callouts dir to includes to pick up dispatcher defines * src/nm-device.c - (nm_device_state_changed): call dispatcher on device activated/ deactivated * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_set_vpn_state): call dispatcher when VPN connections go up and down * src/NetworkManagerUtils.c src/NetworkManagerUtils.h - (nm_utils_call_dispatcher): helper to call dispatcher git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3607 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-27 14:30:06 +00:00
device: leave device up when setting it as unmanaged by user Before, setting a device to unmanaged causes it to go down and clear the interface state. It may be useful to instruct NetworkManager not to touch the device anymore but leave the current state up. Changing behavior for nmcli device set "$DEV" managed no To get the previous behavior, one has to first disconnect the interface via nmcli device disconnect "$DEV" nmcli device set "$DEV" managed no Note that non-permanent addresses like from DHCP will eventually time out because NetworkManager stops the DHCP client. When instructing NetworkManager to let go of the device, you have to take it over in any way you see fit. https://bugzilla.redhat.com/show_bug.cgi?id=1371433
2017-04-18 14:46:27 +02:00
if ( state > NM_DEVICE_STATE_UNMANAGED
&& state <= NM_DEVICE_STATE_ACTIVATED
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
&& nm_device_state_reason_check (reason) == NM_DEVICE_STATE_REASON_NOW_MANAGED
&& NM_IN_SET_TYPED (NMDeviceSysIfaceState,
priv->sys_iface_state,
NM_DEVICE_SYS_IFACE_STATE_EXTERNAL,
NM_DEVICE_SYS_IFACE_STATE_ASSUME))
nm_device_sys_iface_state_set (self, NM_DEVICE_SYS_IFACE_STATE_MANAGED);
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
if ( state <= NM_DEVICE_STATE_DISCONNECTED
|| state >= NM_DEVICE_STATE_ACTIVATED)
priv->auth_retries = NM_DEVICE_AUTH_RETRIES_UNSET;
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
if (state > NM_DEVICE_STATE_DISCONNECTED)
nm_device_assume_state_reset (self);
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
if (state <= NM_DEVICE_STATE_UNAVAILABLE) {
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
if (available_connections_del_all (self))
device: drop available_connections_notify() and call _notify() directly
2016-04-13 14:59:43 +02:00
_notify (self, PROP_AVAILABLE_CONNECTIONS);
device: only clear the activate request when the device disconnects If it's traversing from unavailable to disconnected (e.g. realizing of the device was delayed because it was awaiting the parent connection), then we just want to progress the activation.
2016-03-23 14:51:34 +01:00
if (old_state > NM_DEVICE_STATE_UNAVAILABLE)
_clear_queued_act_request (priv);
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
}
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
/* Update the available connections list when a device first becomes available */
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
if (state >= NM_DEVICE_STATE_DISCONNECTED && old_state < NM_DEVICE_STATE_DISCONNECTED)
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_recheck_available_connections (self);
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
if (state <= NM_DEVICE_STATE_DISCONNECTED || state > NM_DEVICE_STATE_DEACTIVATING) {
if (nm_clear_g_free (&priv->current_stable_id))
_LOGT (LOGD_DEVICE, "stable-id: clear");
}
2008-04-17 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (nm_device_state_changed): do deactivation and and promotion to unavailable here, so that the device gets cleaned up before the manager runs and starts emitting signals; do the FAILED->DISCONNECTED transition from an idle handler rather than immediately to guard against recursion - (nm_device_deactivate_quickly, nm_device_dispose): stop the FAILED->DISCONNECTED handler if it's scheduled git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3573 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-17 23:04:34 +00:00
/* Handle the new state here; but anything that could trigger
* another state change should be done below.
*/
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
switch (state) {
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
case NM_DEVICE_STATE_UNMANAGED:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_set_firmware_missing (self, FALSE);
core: remove bring_up, take_down, is_up device class methods These turn out to be pretty useless, since their functions are already covered by each device's state-changed handler or can be done in other places like deactivate(). https://bugzilla.gnome.org/show_bug.cgi?id=702190
2013-06-12 10:48:03 -05:00
if (old_state > NM_DEVICE_STATE_UNMANAGED) {
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (priv->sys_iface_state != NM_DEVICE_SYS_IFACE_STATE_MANAGED) {
nm_device_cleanup (self, reason,
priv->sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_REMOVED
? CLEANUP_TYPE_REMOVED
: CLEANUP_TYPE_KEEP);
} else {
device: do not touch sysctls after the device was removed Paths to sysctls don't use ifindex and device names can be reused. If someone removes a device and quickly creates a device with the same name, chances are we're cleaning up the device that was just added. Sadly, it seems there's no better API than sysctl-- neither netlink nor procfs symlinks with ifindex or anything like that.
2015-03-16 18:19:05 +01:00
/* Clean up if the device is now unmanaged but was activated */
if (nm_device_get_act_request (self))
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
nm_device_cleanup (self, reason, CLEANUP_TYPE_DECONFIGURE);
device: do not touch sysctls after the device was removed Paths to sysctls don't use ifindex and device names can be reused. If someone removes a device and quickly creates a device with the same name, chances are we're cleaning up the device that was just added. Sadly, it seems there's no better API than sysctl-- neither netlink nor procfs symlinks with ifindex or anything like that.
2015-03-16 18:19:05 +01:00
nm_device_take_down (self, TRUE);
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
nm_device_hw_addr_reset (self, "unmanage");
device: do not touch sysctls after the device was removed Paths to sysctls don't use ifindex and device names can be reused. If someone removes a device and quickly creates a device with the same name, chances are we're cleaning up the device that was just added. Sadly, it seems there's no better API than sysctl-- neither netlink nor procfs symlinks with ifindex or anything like that.
2015-03-16 18:19:05 +01:00
set_nm_ipv6ll (self, FALSE);
restore_ip6_properties (self);
device: mark uses of device's state-reason with nm_device_state_reason_check() The state-change of a device has a reason argument, which is mostly for information only. There are many places in code that are the source of a state-reason. Mostly these are calls to: - nm_device_state_changed() - nm_device_queue_state() - nm_device_queue_recheck_available() - nm_device_set_unmanaged_by_*() - nm_device_master_release_one_slave() - nm_device_ip_method_failed() - nm_modem_emit_prepare_result() - nm_modem_emit_ppp_failed() - nm_manager_deactivate_connection() - NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_*); However, there are a few places in code that look at the reason to decide how to proceed. I think this is a bad pattern, because cause and effect are decoupled and it gets hard to understand where a certain reason is set and what consequences that has. Add a nop-function nm_device_state_reason_check() to mark all uses of the device state reason that derive decisions from it. That is, highlight the "effect" part.
2017-02-23 15:19:03 +01:00
break;
device: do not touch sysctls after the device was removed Paths to sysctls don't use ifindex and device names can be reused. If someone removes a device and quickly creates a device with the same name, chances are we're cleaning up the device that was just added. Sadly, it seems there's no better API than sysctl-- neither netlink nor procfs symlinks with ifindex or anything like that.
2015-03-16 18:19:05 +01:00
}
core: remove bring_up, take_down, is_up device class methods These turn out to be pretty useless, since their functions are already covered by each device's state-changed handler or can be done in other places like deactivate(). https://bugzilla.gnome.org/show_bug.cgi?id=702190
2013-06-12 10:48:03 -05:00
}
2008-04-28 Dan Williams <dcbw@redhat.com> Fix the device up/down ambiguities. Up/down state used to be a conglomeration of hardware state (IFF_UP) and any device-specific things (supplicant, periodic timers, etc) that the device used to indicate readiness. Unfortunately, if the hardware was already IFF_UP for some reason, then the device specific stuff wouldn't get run, and the device would be stuck. * src/nm-device.c src/nm-device.h - Create hw_is_up, hw_bring_up, and hw_take_down - Rename bring_down -> take_down - (real_hw_is_up): check interface flags for IFF_UP - (nm_device_hw_is_up): let subclasses figure out their own HW state - (nm_device_is_up): make static; only used locally - (nm_device_hw_bring_up): update the hardware and IPv4 addresses even if the device is already up; if the device isn't up, bring it up - (nm_device_hw_take_down): just take down hardware - (nm_device_bring_up): bring up HW first, then device specific stuff - (nm_device_take_down): always deactivate device when called; always try to take hardware down too - (nm_device_state_changed): take device down when entering unmanaged state from a higher state * src/nm-device-802-11-wireless.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really - (real_take_down, supplicant_iface_state_cb_handler, supplicant_iface_connection_state_cb_handler, supplicant_mgr_state_cb_handler): fix some messages * src/nm-device-802-3-ethernet.c - (real_hw_is_up, real_hw_bring_up, real_hw_take_down): implement; just check IFF_UP really git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3618 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-29 15:36:29 +00:00
break;
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
case NM_DEVICE_STATE_UNAVAILABLE:
devices: enable/disable kernel IPv6 autoconf at the appropriate times Set accept_ra and use_tempaddr to "0" when managing a device (and restore them to their original values after unmanaging it) to ensure that calling nm_device_bring_up() on a managed device won't ever cause kernel IPv6 autoconf to happen. Remove some other redundant accept_ra setting. Fix up the deconfigure case of dispose() to clear the device's IP6 config as well as its IP4 config. https://bugzilla.gnome.org/show_bug.cgi?id=700414
2013-10-24 13:55:06 -04:00
if (old_state == NM_DEVICE_STATE_UNMANAGED) {
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
save_ip6_properties (self);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (priv->sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_MANAGED)
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
ip6_managed_setup (self);
devices: enable/disable kernel IPv6 autoconf at the appropriate times Set accept_ra and use_tempaddr to "0" when managing a device (and restore them to their original values after unmanaging it) to ensure that calling nm_device_bring_up() on a managed device won't ever cause kernel IPv6 autoconf to happen. Remove some other redundant accept_ra setting. Fix up the deconfigure case of dispose() to clear the device's IP6 config as well as its IP4 config. https://bugzilla.gnome.org/show_bug.cgi?id=700414
2013-10-24 13:55:06 -04:00
}
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (priv->sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_MANAGED) {
core: don't bring up devices using assumed connections (bgo #725647) (rh #1030947) We want to export the IP configuration of interfaces when they have some, but the kernel doesn't care if they are IFF_UP or not. Neither should NetworkManager, so don't force devices IFF_UP just because we're assuming their IP config.
2014-12-05 14:13:28 -06:00
if (old_state == NM_DEVICE_STATE_UNMANAGED || priv->firmware_missing) {
if (!nm_device_bring_up (self, TRUE, &no_firmware) && no_firmware)
logging: remove LOGD_HW alias for LOGD_PLATFORM Since commit 1495853e01299d1eb33d4eb10b91e37dcf855cc8, LOGD_HW is renamed to LOGD_PLATFORM. Remove the internal usage of the deprecated name.
2016-10-06 21:28:40 +02:00
_LOGW (LOGD_PLATFORM, "firmware may be missing.");
core: don't bring up devices using assumed connections (bgo #725647) (rh #1030947) We want to export the IP configuration of interfaces when they have some, but the kernel doesn't care if they are IFF_UP or not. Neither should NetworkManager, so don't force devices IFF_UP just because we're assuming their IP config.
2014-12-05 14:13:28 -06:00
nm_device_set_firmware_missing (self, no_firmware ? TRUE : FALSE);
}
/* Ensure the device gets deactivated in response to stuff like
* carrier changes or rfkill. But don't deactivate devices that are
* about to assume a connection since that defeats the purpose of
* assuming the device's existing connection.
*
* Note that we "deactivate" the device even when coming from
* UNMANAGED, to ensure that it's in a clean state.
*/
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
nm_device_cleanup (self, reason, CLEANUP_TYPE_DECONFIGURE);
core: don't bring up devices using assumed connections (bgo #725647) (rh #1030947) We want to export the IP configuration of interfaces when they have some, but the kernel doesn't care if they are IFF_UP or not. Neither should NetworkManager, so don't force devices IFF_UP just because we're assuming their IP config.
2014-12-05 14:13:28 -06:00
}
core: implement connection assumption Mark activation requests that contain connections to be assumed, and use that to short-circuit various parts of the activation process by not touching various device attributes, since they are already set up. Also ensure the device is not deactivated when it initially becomes managed, because that would kill the connection we are about to assume.
2009-08-05 18:03:09 -04:00
break;
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
case NM_DEVICE_STATE_DISCONNECTED:
core: bounce disable_ipv6 when setting userspace IPv6 link-local (bgo #740096) The kernel does not terminate an ongoing IPv6LL address process when the IPv6LL address generation mode is set to 'none' (indicating that userspace wishes to handle IPv6LL). Next, NetworkManager does not expose IPv6 addresses internally until they have completed DAD. This means that the kernel may still be performing DAD for an IPv6LL address when NetworkManager turns userspace IPv6LL on, and when DAD is complete NetworkManager will finally pay attention to the address. If the device is in the DISCONNECTED state, NetworkManager will then generate and assume an IPv6LL-only connection on the device. Unfortunately, that behavior happens if the following is true: 1) IPv6LL addressing takes a while (eg, dad_transmits is high or the kernel takes a while for some reason) 2) the activated connection fails quickly (dhclient fails or some other fatal error terminates the activation attempt) 3) the activated connection has ipv6.method=ignore In this case, when the device was brought up and ipv6.method=ignore, NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl properties. The kernel then generated an IPv6LL address and began DAD. dhclient failed quickly, and NM deactivated the device. NM then turned off kernel IPv6LL when deactivating the device, but the kernel does not terminate the ongoing DAD. Some time after the device entered the DISCONNECTED state, the kernel finished DAD and that allowed NetworkManager to internally see the address, which caused NetworkManager to emit the 'recheck-assume' signal. This generated a new IPv6LL-only connection which was then assumed. Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during device deactivation flushes the tentative kernel IPv6LL address, thus preventing the address from being announced after userspace IPv6LL is re-enabled. The other alternative is to expose tentative addresses (eg those still doing DAD) in NMPlatform so they would be flushed when the device deactivates, but that is a larger & riskier set of changes. Reproducer: - ifconfig eth0 down - prepare a DHCPv4 connection with ipv6.method=ignore - set /proc/sys/net/ipv6/conf/all/dad_transmits to "15" - ensure that DHCPv4 will fail (replace dhclient with a script that exits after 2 seconds or something) - run NetworkManager - activate the DHCP connection and watch it immediately fail - wait for the kernel to announce the IPv6LL address after DAD finishes - watch NM "assume" the new IPv6LL connection https://bugzilla.gnome.org/show_bug.cgi?id=740096
2014-11-13 19:52:21 -06:00
if (old_state > NM_DEVICE_STATE_DISCONNECTED) {
/* Ensure devices that previously assumed a connection now have
* userspace IPv6LL enabled.
*/
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
set_nm_ipv6ll (self, TRUE);
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
nm_device_cleanup (self, reason, CLEANUP_TYPE_DECONFIGURE);
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
} else if (old_state < NM_DEVICE_STATE_DISCONNECTED) {
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (priv->sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_MANAGED) {
core: don't manage externally created software devices until IFF_UP (rh #1030947) (bgo #725647) Externally created software devices would be managed/assumed immediately upon creation, which includes setting them IFF_UP and possibly turning on NM-managed IPv6LL. With this commit, expected behavior for external software devices is: 1) created: unmanaged state, no further action 2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP 3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP 3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED This branch ensures that external software devices are not set IFF_UP by NetworkManager when they are discovered. It additionally ensures that they are not set IFF_UP during connection assumption. They may be set IFF_UP later through specific user action. https://bugzilla.gnome.org/show_bug.cgi?id=725647 https://bugzilla.redhat.com/show_bug.cgi?id=1030947
2014-12-03 12:47:30 -06:00
/* Ensure IPv6 is set up as it may not have been done when
* entering the UNAVAILABLE state depending on the reason.
*/
ip6_managed_setup (self);
}
core: bounce disable_ipv6 when setting userspace IPv6 link-local (bgo #740096) The kernel does not terminate an ongoing IPv6LL address process when the IPv6LL address generation mode is set to 'none' (indicating that userspace wishes to handle IPv6LL). Next, NetworkManager does not expose IPv6 addresses internally until they have completed DAD. This means that the kernel may still be performing DAD for an IPv6LL address when NetworkManager turns userspace IPv6LL on, and when DAD is complete NetworkManager will finally pay attention to the address. If the device is in the DISCONNECTED state, NetworkManager will then generate and assume an IPv6LL-only connection on the device. Unfortunately, that behavior happens if the following is true: 1) IPv6LL addressing takes a while (eg, dad_transmits is high or the kernel takes a while for some reason) 2) the activated connection fails quickly (dhclient fails or some other fatal error terminates the activation attempt) 3) the activated connection has ipv6.method=ignore In this case, when the device was brought up and ipv6.method=ignore, NetworkManager re-enabled kernel IPv6LL and reset the IPv6 sysctl properties. The kernel then generated an IPv6LL address and began DAD. dhclient failed quickly, and NM deactivated the device. NM then turned off kernel IPv6LL when deactivating the device, but the kernel does not terminate the ongoing DAD. Some time after the device entered the DISCONNECTED state, the kernel finished DAD and that allowed NetworkManager to internally see the address, which caused NetworkManager to emit the 'recheck-assume' signal. This generated a new IPv6LL-only connection which was then assumed. Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during device deactivation flushes the tentative kernel IPv6LL address, thus preventing the address from being announced after userspace IPv6LL is re-enabled. The other alternative is to expose tentative addresses (eg those still doing DAD) in NMPlatform so they would be flushed when the device deactivates, but that is a larger & riskier set of changes. Reproducer: - ifconfig eth0 down - prepare a DHCPv4 connection with ipv6.method=ignore - set /proc/sys/net/ipv6/conf/all/dad_transmits to "15" - ensure that DHCPv4 will fail (replace dhclient with a script that exits after 2 seconds or something) - run NetworkManager - activate the DHCP connection and watch it immediately fail - wait for the kernel to announce the IPv6LL address after DAD finishes - watch NM "assume" the new IPv6LL connection https://bugzilla.gnome.org/show_bug.cgi?id=740096
2014-11-13 19:52:21 -06:00
}
2007-03-02 Tambet Ingo <tambet@ximian.com> * libnm-glib/nm-device-802-11-wireless.c: Cache networks (bssids) list. We get signalled when it changes. * libnm-glib/nm-client.c: Cache NMState and device list, we get signalled when it changes. * libnm-glib/nm-device.c: Cache the device state property. * libnm-glib/nm-access-point.c: Cache the strength property. * src/nm-device-802-11-wireless.c: Fix wireless device scanning scheduler. The new algorithm is to start from SCAN_INTERVAL_MIN (currently defined as 0) and add a SCAN_INTERVAL_STEP (currently 20 seconds) with each successful scan until SCAN_INTERVAL_MAX (currently 120 seconds) is reached. Do not scan while the device is down, activating, or activated (in case of A/B/G cards). Remove some old dead ifdef'ed out code that used to configure wireless devices, it's all done through supplicant now. * src/supplicant-manager/nm-supplicant-interface.c: Fix the reference counting issues with pending calls which caused leaks and crashes when interface was removed (now that the interface actually gets removed). * src/nm-call-store.c: Make a copy of data before running a foreach with user callback on it - The most common usage pattern is to cancel (and thus remove) all pending calls with foreach which would modify the hash table we're iterating over. * src/nm-manager.c: When a device is added, make sure it is "up". When it's removed or disabled due to disabling wireless or networking, bring it down. * include/NetworkManager.h: Add new device state NM_DEVICE_STATE_DOWN. * src/nm-device-802-11-wireless.c: * src/nm-device-802-3-ethernet.c: * src/nm-device.c: - Remove "init" virtual function, all gobjects have a place for that already (constructor). - Replace "start" virtual function with "bring_up", devices can be brought up and down more than just on startup now. - Add "is_up" virtual function. - Implement one way to bring a device down instead of previous 4 different ways, each of witch did something different. * src/NetworkManagerUtils.c (nm_dev_sock_open): This doesn't need an NMDevice, all it needs is the device interface. Get rid of NMData.dev_list (3 members to go). Get rif of NMData in a lot of places. * gnome/libnm_glib/libnm_glib.c: Make it compile again. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2395 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-03-02 09:30:48 +00:00
break;
device: re-read initial hw-address before activating connection Previously, we would only once read the initial hardware address during device realization. When a device activates, NetworkManager always sets the MAC address as configured in the cloned-mac-address setting -- or, if unspecified -- it falls back to use the permanent hardware-address instead. Later, when deactivating the device, the MAC address is reset to the "inital MAC address". This patch changes, that the "initial MAC address" is re-read every time before activating the device, contrary to reading it once in the beginning. This allows for a user to first start NetworkManager and later change the MAC address of the device. When activating the device, NM will reset the MAC address for the time the device is active. But when disconnecting, it resets to the user-changed value, not the value when NM was started. https://bugzilla.gnome.org/show_bug.cgi?id=708820
2016-05-20 18:10:51 +02:00
case NM_DEVICE_STATE_PREPARE:
nm_device_update_initial_hw_address (self);
break;
core: clean up half-done IP operations when re-entering NEED_AUTH state (bgo #741342) When the device decides it needs re-auth during IP config and returns to the NEED_AUTH state, make sure we clean up any half-done IP operations since they will be re-started after auth is completed and the IP_CONFIG state is re-entered. https://bugzilla.gnome.org/show_bug.cgi?id=741342
2014-12-10 10:23:40 -06:00
case NM_DEVICE_STATE_NEED_AUTH:
if (old_state > NM_DEVICE_STATE_NEED_AUTH) {
/* Clean up any half-done IP operations if the device's layer2
* finds out it needs authentication during IP config.
*/
device: refactor the ip cleanup Split it up and move upwards. It will be useful for runtime reconfig of IPv4 configuration.
2015-11-21 12:28:09 +01:00
_cleanup_ip4_pre (self, CLEANUP_TYPE_DECONFIGURE);
_cleanup_ip6_pre (self, CLEANUP_TYPE_DECONFIGURE);
core: clean up half-done IP operations when re-entering NEED_AUTH state (bgo #741342) When the device decides it needs re-auth during IP config and returns to the NEED_AUTH state, make sure we clean up any half-done IP operations since they will be re-started after auth is completed and the IP_CONFIG state is re-entered. https://bugzilla.gnome.org/show_bug.cgi?id=741342
2014-12-10 10:23:40 -06:00
}
break;
2008-04-17 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (nm_device_state_changed): do deactivation and and promotion to unavailable here, so that the device gets cleaned up before the manager runs and starts emitting signals; do the FAILED->DISCONNECTED transition from an idle handler rather than immediately to guard against recursion - (nm_device_deactivate_quickly, nm_device_dispose): stop the FAILED->DISCONNECTED handler if it's scheduled git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3573 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-17 23:04:34 +00:00
default:
break;
}
device: improve tracking autoconnect-blocked flags of NMDevice - split NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN in two parts: "wrong-pin" and "manual-disconnect". Setting/unsetting them should be tracked differently, as their reason differs. - no longer initialize/clear the autoconnect-blocked reasons during realize/unrealize of the device. Instead, initialize it once when the object gets created (nm_device_init()), and keep the settings beyond unrealize/realize cycles. This only matters for software devices, as regular devices get deleted after unrealizing once. But for software devices it is essential, because we don't want to forget the autoconnect settings of the device instance. - drop verbose logging about blocking autoconnect due to failed pin. We already log changes to autoconnect-blocked flags with TRACE level. An additional message about this particular issue seems not necessary at INFO level. - in NMManager's do_sleep_wake(), no longer block autoconnect for devices during sleep. We already unmanage the device, which is a far more effective measure to prevent activation. We should not also block autoconnect.
2017-11-07 12:36:17 +01:00
/* Reset intern autoconnect flags when the device is activating or connected. */
core: fix a regression in manual device disconnection (bgo #726239) Devices disconnected explicitly by user should stay disconnected, preventing auto-connecting until manual request. Introduction of NM_DEVICE_STATE_DEACTIVATING state broke this feature. disconnect_cb() correctly set autoconnect device property to FALSE, however nm_device_state_changed() put it to TRUE again. Thus only the active connection was blocked instead of the whole device. https://bugzilla.gnome.org/show_bug.cgi?id=726239
2014-03-13 14:37:26 +01:00
if ( state >= NM_DEVICE_STATE_PREPARE
&& state <= NM_DEVICE_STATE_ACTIVATED)
device: improve tracking autoconnect-blocked flags of NMDevice - split NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN in two parts: "wrong-pin" and "manual-disconnect". Setting/unsetting them should be tracked differently, as their reason differs. - no longer initialize/clear the autoconnect-blocked reasons during realize/unrealize of the device. Instead, initialize it once when the object gets created (nm_device_init()), and keep the settings beyond unrealize/realize cycles. This only matters for software devices, as regular devices get deleted after unrealizing once. But for software devices it is essential, because we don't want to forget the autoconnect settings of the device instance. - drop verbose logging about blocking autoconnect due to failed pin. We already log changes to autoconnect-blocked flags with TRACE level. An additional message about this particular issue seems not necessary at INFO level. - in NMManager's do_sleep_wake(), no longer block autoconnect for devices during sleep. We already unmanage the device, which is a far more effective measure to prevent activation. We should not also block autoconnect.
2017-11-07 12:36:17 +01:00
nm_device_autoconnect_blocked_unset (self, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERNAL);
core: fix a regression in manual device disconnection (bgo #726239) Devices disconnected explicitly by user should stay disconnected, preventing auto-connecting until manual request. Introduction of NM_DEVICE_STATE_DEACTIVATING state broke this feature. disconnect_cb() correctly set autoconnect device property to FALSE, however nm_device_state_changed() put it to TRUE again. Thus only the active connection was blocked instead of the whole device. https://bugzilla.gnome.org/show_bug.cgi?id=726239
2014-03-13 14:37:26 +01:00
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_STATE);
_notify (self, PROP_STATE_REASON);
device: cast enum types for variadic g_signal_emit() function
2017-03-06 12:23:23 +01:00
g_signal_emit (self, signals[STATE_CHANGED], 0, (guint) state, (guint) old_state, (guint) reason);
2008-04-17 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (nm_device_state_changed): do deactivation and and promotion to unavailable here, so that the device gets cleaned up before the manager runs and starts emitting signals; do the FAILED->DISCONNECTED transition from an idle handler rather than immediately to guard against recursion - (nm_device_deactivate_quickly, nm_device_dispose): stop the FAILED->DISCONNECTED handler if it's scheduled git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3573 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-17 23:04:34 +00:00
2008-04-27 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-dispatcher-action.c callouts/nm-dispatcher-action.h callouts/nm-dispatcher.conf callouts/nm-dispatcher.xml callouts/org.freedesktop.nm_dispatcher.service - Re-implement the dispatcher as a system-bus activated service that NM calls on-demand, rather than an always running daemon * src/Makefile.am - Add callouts dir to includes to pick up dispatcher defines * src/nm-device.c - (nm_device_state_changed): call dispatcher on device activated/ deactivated * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_set_vpn_state): call dispatcher when VPN connections go up and down * src/NetworkManagerUtils.c src/NetworkManagerUtils.h - (nm_utils_call_dispatcher): helper to call dispatcher git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3607 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-27 14:30:06 +00:00
/* Post-process the event after internal notification */
2008-04-17 Dan Williams <dcbw@redhat.com> * src/nm-device.c - (nm_device_state_changed): do deactivation and and promotion to unavailable here, so that the device gets cleaned up before the manager runs and starts emitting signals; do the FAILED->DISCONNECTED transition from an idle handler rather than immediately to guard against recursion - (nm_device_deactivate_quickly, nm_device_dispose): stop the FAILED->DISCONNECTED handler if it's scheduled git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3573 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-17 23:04:34 +00:00
switch (state) {
core: generalize unavailable -> disconnected delayed transition Instead of doing this in every device subclass, do it in the NMDevice superclass. nm_device_can_activate() already did the same logic that each of the subclass device_state_changed() handlers were doing to figure out whether they could do the transition from unavailable to disconnected, so just use that in NMDevice and kill lots of code.
2009-09-14 13:24:29 -07:00
case NM_DEVICE_STATE_UNAVAILABLE:
/* If the device can activate now (ie, it's got a carrier, the supplicant
* is active, or whatever) schedule a delayed transition to DISCONNECTED
trivial: typo fixes Sent by a Debian user to Michael Biebl. No other attribution information available. Thanks Debian user!
2010-09-25 00:34:10 -05:00
* to get things rolling. The device can't transition immediately because
core: generalize unavailable -> disconnected delayed transition Instead of doing this in every device subclass, do it in the NMDevice superclass. nm_device_can_activate() already did the same logic that each of the subclass device_state_changed() handlers were doing to figure out whether they could do the transition from unavailable to disconnected, so just use that in NMDevice and kill lots of code.
2009-09-14 13:24:29 -07:00
* we can't change states again from the state handler for a variety of
* reasons.
*/
device: add flags to nm_device_is_available()
2015-01-20 20:25:25 +01:00
if (nm_device_is_available (self, NM_DEVICE_CHECK_DEV_AVAILABLE_NONE)) {
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
nm_device_queue_recheck_available (self,
NM_DEVICE_STATE_REASON_NONE,
NM_DEVICE_STATE_REASON_NONE);
core: fix device log message in UNAVAILABLE state
2010-04-08 15:51:54 -07:00
} else {
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
_LOGD (LOGD_DEVICE, "device not yet available for transition to DISCONNECTED");
core: log device delayed state transitions
2010-04-07 16:41:44 -07:00
}
core: generalize unavailable -> disconnected delayed transition Instead of doing this in every device subclass, do it in the NMDevice superclass. nm_device_can_activate() already did the same logic that each of the subclass device_state_changed() handlers were doing to figure out whether they could do the transition from unavailable to disconnected, so just use that in NMDevice and kill lots of code.
2009-09-14 13:24:29 -07:00
break;
devices: start using the DEACTIVATING state When a device is disconnected by the user (as opposed to due to network or hardware error, etc), set it first to DEACTIVATING, which does nothing but queue a transition to disconnected. This lets other parts of NM observe the device when it is about-to-disconnect, but still has an associated connection.
2014-01-03 13:58:05 -05:00
case NM_DEVICE_STATE_DEACTIVATING:
manager: remove a connection from device if we're activating it on another device The connection now might be being activated on another device. Defer the removal until we're sure the activation request will proceed and only add the active connection afterwards. https://bugzilla.gnome.org/show_bug.cgi?id=730492
2015-02-03 16:15:37 +01:00
_cancel_activation (self);
device: fix multiple subscriptions to config-changed signal for ignore-carrier We would subscribe to config-changed signal during object-realize, however only unsubscribe during dispose(). Avoid multiple subscributions, and unsubscribe also when unrealizing the device. Also, always subscribe to the signal, even without capability NM_DEVICE_CAP_CARRIER_DETECT. In the next commit, we will re-read capabilities later on, so just always subscribe.
2016-05-11 16:53:16 +02:00
/* We cache the ignore_carrier state to not react on config-reloads while the connection
* is active. But on deactivating, reset the ignore-carrier flag to the current state. */
priv->ignore_carrier = nm_config_data_get_ignore_carrier (NM_CONFIG_GET_DATA, self);
device: allow reloading of the ignore-carrier flag Now on SIGHUP, when reloading NetworkManager configuration, also reload the ignore-carrier flag. While a device is activated, the reload is ignored until the device deactivates. Maybe it would be simpler just not to cache ignore_carrer and let it take effect immediately. But not caching ignore_carrer has the additional downside that every call to is_available must check the specs -- which in sum is potentially expensive for something that almost never changes. https://bugzilla.gnome.org/show_bug.cgi?id=748050
2015-04-17 14:12:10 +02:00
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
if (quitting) {
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
nm_dispatcher_call_device_sync (NM_DISPATCHER_ACTION_PRE_DOWN,
self, req);
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
} else {
device: refactor by combining dispatcher callback functions Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-06-12 14:20:14 +02:00
priv->dispatcher.post_state = NM_DEVICE_STATE_DISCONNECTED;
priv->dispatcher.post_state_reason = reason;
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
if (!nm_dispatcher_call_device (NM_DISPATCHER_ACTION_PRE_DOWN,
self,
req,
deactivate_dispatcher_complete,
self,
&priv->dispatcher.call_id)) {
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
/* Just proceed on errors */
device: new deactivate_async() method to be run during DEACTIVATING phase This method isn't run if NM is quitting; so the deactivate() method still needs to be implemented to handle sync disconnection requests.
2014-08-05 20:08:34 +02:00
deactivate_dispatcher_complete (0, self);
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
}
core: implement PRE_DOWN dispatcher actions (bgo #387832) https://bugzilla.gnome.org/show_bug.cgi?id=387832
2014-05-20 17:10:42 -05:00
}
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
nm_pacrunner_manager_remove_clear (priv->pacrunner_manager,
&priv->pacrunner_call_id);
devices: start using the DEACTIVATING state When a device is disconnected by the user (as opposed to due to network or hardware error, etc), set it first to DEACTIVATING, which does nothing but queue a transition to disconnected. This lets other parts of NM observe the device when it is about-to-disconnect, but still has an associated connection.
2014-01-03 13:58:05 -05:00
break;
core: add a "default-unmanaged" setting for devices Allow devices to declare themselves unmanaged-by-default, but tweak nm-manager and nm-policy to allow activating matching connections on those devices anyway. (This ensures that NM keeps its hands completely off the device unless the user explicitly asks it to do something with it.)
2013-04-24 10:40:58 -04:00
case NM_DEVICE_STATE_DISCONNECTED:
device: accept user activation request while waiting for carrier https://bugzilla.redhat.com/show_bug.cgi?id=1079353
2014-12-08 12:50:10 +01:00
if ( priv->queued_act_request
&& !priv->queued_act_request_is_waiting_for_carrier) {
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
NMActRequest *queued_req;
queued_req = priv->queued_act_request;
priv->queued_act_request = NULL;
device: remove useless check and var with the rework in commit #87a3df2e572ed47b5f76f6d1cad63ce622296e21 the check of the return value of _device_activate () is no more needed. Remove useless check and var.
2017-05-17 11:34:54 +02:00
_device_activate (self, queued_req);
core: queue re-activations to allow DEACTIVATING state If a device is already activated, queue the new activation to allow the transition through the DEACTIVATING state. --- Also remove the "HACK" bits in nm_device_deactivate(). This hack was added on 2007-09-25 in commit 9c2848d. At the time, with user settings services, if a client created a connection and requested that NM activate it, NM may not have read the connection from the client over D-Bus yet. So NM created a "deferred" activation request which waited until the connection was read from the client, and then began activation. The Policy watched for device state changes and other events (like it does now) and activated a new device if the old one was no longer valid. It specifically checked for deferred activations and then did nothing. However, when the client's connection was read, then nm-device.c cleared the deferred activation bit, leading to a short period of time where the device was in DISCONNECTED state but there was no deferred activation, because the device only changes state to PREPARE from the idle handler for stage1. If other events happened during this time, the policy would tear down the device that was about to be activated. This early state transition to PREPARE worked around that. We need to remove it now though, because (a) the reason for its existence is no longer valid, and (b) _device_activate() may now be called from inside nm_device_state_changed() and thus it cannot change to a new state inside the function.
2014-02-17 17:16:08 -06:00
g_object_unref (queued_req);
core: don't activate failed queued activation requests If the queued activation request failed before the device is finished deactiving the old request, don't start activating the failed queued request.
2014-10-16 15:01:16 -05:00
}
core: add a "default-unmanaged" setting for devices Allow devices to declare themselves unmanaged-by-default, but tweak nm-manager and nm-policy to allow activating matching connections on those devices anyway. (This ensures that NM keeps its hands completely off the device unless the user explicitly asks it to do something with it.)
2013-04-24 10:40:58 -04:00
break;
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
case NM_DEVICE_STATE_ACTIVATED:
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGI (LOGD_DEVICE, "Activation: successful, device activated.");
core: update device 'metered' property on connection state change The metered property of a NMDevice that reaches the activated state is copied from the active connection and if its value is 'unknown' some heuristics are used to guess the actual value. When the connection is torn down the metered property is reset to 'unknown'.
2015-04-30 14:18:14 +02:00
nm_device_update_metered (self);
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
nm_dispatcher_call_device (NM_DISPATCHER_ACTION_UP,
self,
req,
NULL, NULL, NULL);
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
if (priv->proxy_config)
_pacrunner_manager_send (self);
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
break;
case NM_DEVICE_STATE_FAILED:
device: terminate the activation chain when entering the failed state Device activation normally fails during one of the stages and in that case the activation chain is implicitly interrupted. But in some cases the device fails for external events (as a failure of master connection) while the activation sequence is still running and so we need to ensure that any pending activation source gets cleared upon entering the failed state. https://bugzilla.redhat.com/show_bug.cgi?id=1270814
2015-11-03 22:38:55 +01:00
/* Usually upon failure the activation chain is interrupted in
* one of the stages; but in some cases the device fails for
* external events (as a failure of master connection) while
* the activation sequence is running and so we need to ensure
* that the chain is terminated here.
*/
_cancel_activation (self);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
if (nm_device_sys_iface_state_is_external_or_assume (self)) {
device: don't disconnect assumed connections Transition them to activated status when they fail. https://bugzilla.redhat.com/show_bug.cgi?id=1141264
2014-12-03 14:47:44 +01:00
/* Avoid tearing down assumed connection, assume it's connected */
nm_device_queue_state (self,
NM_DEVICE_STATE_ACTIVATED,
NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED);
break;
}
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection = nm_device_get_settings_connection (self);
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGW (LOGD_DEVICE | LOGD_WIFI,
"Activation: failed for connection '%s'",
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
connection ? nm_settings_connection_get_id (connection) : "<unknown>");
core: determine whether connection timestamps are set or not Currently there's no way to differentiate between a connection that has never been activated, and a connection that has never been *successfully* activated. In both cases nm_settings_connection_get_timestamp() returns zero. But it's useful to know whether a connection hasn't even been tried yet, so enhance the timestamp code to return whether or not the timestamp has been found in the timestamp cache or not, and make the NMDevice core set an explict timestamp of 0 if the connection failed on the first attempt. We'll use this later to conditionally autoconnect WiFi connections depending on whether they've ever successfully connected or not, but still allow preloaded connections without a timestamp to autoconnect as they always have.
2012-09-12 22:44:31 -05:00
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
/* Notify any slaves of the unexpected failure */
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_master_release_slaves (self);
core: rework master/slave handling
2012-11-14 14:05:30 -06:00
core: determine whether connection timestamps are set or not Currently there's no way to differentiate between a connection that has never been activated, and a connection that has never been *successfully* activated. In both cases nm_settings_connection_get_timestamp() returns zero. But it's useful to know whether a connection hasn't even been tried yet, so enhance the timestamp code to return whether or not the timestamp has been found in the timestamp cache or not, and make the NMDevice core set an explict timestamp of 0 if the connection failed on the first attempt. We'll use this later to conditionally autoconnect WiFi connections depending on whether they've ever successfully connected or not, but still allow preloaded connections without a timestamp to autoconnect as they always have.
2012-09-12 22:44:31 -05:00
/* If the connection doesn't yet have a timestamp, set it to zero so that
* we can distinguish between connections we've tried to activate and have
* failed (zero timestamp), connections that succeeded (non-zero timestamp),
* and those we haven't tried yet (no timestamp).
*/
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
if (connection && !nm_settings_connection_get_timestamp (connection, NULL))
nm_settings_connection_update_timestamp (connection, (guint64) 0, TRUE);
core: determine whether connection timestamps are set or not Currently there's no way to differentiate between a connection that has never been activated, and a connection that has never been *successfully* activated. In both cases nm_settings_connection_get_timestamp() returns zero. But it's useful to know whether a connection hasn't even been tried yet, so enhance the timestamp code to return whether or not the timestamp has been found in the timestamp cache or not, and make the NMDevice core set an explict timestamp of 0 if the connection failed on the first attempt. We'll use this later to conditionally autoconnect WiFi connections depending on whether they've ever successfully connected or not, but still allow preloaded connections without a timestamp to autoconnect as they always have.
2012-09-12 22:44:31 -05:00
core: generalize unavailable -> disconnected delayed transition Instead of doing this in every device subclass, do it in the NMDevice superclass. nm_device_can_activate() already did the same logic that each of the subclass device_state_changed() handlers were doing to figure out whether they could do the transition from unavailable to disconnected, so just use that in NMDevice and kill lots of code.
2009-09-14 13:24:29 -07:00
/* Schedule the transition to DISCONNECTED. The device can't transition
trivial: typo fixes Sent by a Debian user to Michael Biebl. No other attribution information available. Thanks Debian user!
2010-09-25 00:34:10 -05:00
* immediately because we can't change states again from the state
core: generalize unavailable -> disconnected delayed transition Instead of doing this in every device subclass, do it in the NMDevice superclass. nm_device_can_activate() already did the same logic that each of the subclass device_state_changed() handlers were doing to figure out whether they could do the transition from unavailable to disconnected, so just use that in NMDevice and kill lots of code.
2009-09-14 13:24:29 -07:00
* handler for a variety of reasons.
*/
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_queue_state (self, NM_DEVICE_STATE_DISCONNECTED, NM_DEVICE_STATE_REASON_NONE);
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
break;
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
case NM_DEVICE_STATE_IP_CHECK:
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
if ( priv->fw_state >= FIREWALL_STATE_INITIALIZED
device: fix changing firewall zone during _set_state_full() For regular devices that don't have a separate ip_iface/ip_ifindex, the ip_ifindex is left at zero. Hence, the condition is always true and does not work as intended, resulting in setting the firewall zone twice. Fixes: 7cf5c326bc9a3e3166c682f3d70f65b895f2cd20
2017-05-04 15:04:10 +02:00
&& priv->ip_iface
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
&& !nm_device_sys_iface_state_is_external (self)) {
device: track firewall state and reset zone during activation nm_device_update_firewall_zone() would only reconfigure the firewall zone when the device is fully activated. That means, while the device is activating, changing the firewall zone is not working. Activation might take a long time with DHCP, or with master devices waiting for their slaves. For example: nmcli connection add type team con-name t-team ifname i-team autoconnect no nmcli connection up t-team Note how t-team/i-team is waiting for a slave device. During stage3, we already set firewall.zone to default. nmcli connection modify t-team connection.zone external Note how changing the firewall zone does not immidiately take effect. Only later, during IP_CHECK state the firewall zone is reset -- but only for devices with differing ip_ifindex. https://bugzilla.redhat.com/show_bug.cgi?id=1445242
2017-05-03 18:34:17 +02:00
priv->fw_state = FIREWALL_STATE_WAIT_IP_CONFIG;
fw_change_zone (self);
device: ensure firewall zone is set on the actual IP interface For certain types of connection as PPP and WWAN the IP interface is created during stage3 (IP config) but we are setting the firewall zone at the beginning of stage3 and thus the zone is only set on the underlying interface. Add a check at the start of IP check phase to ensure that the firewall zone is set again if the device interface is different from IP interface. https://bugzilla.redhat.com/show_bug.cgi?id=1110465
2015-09-17 13:41:34 +02:00
} else
nm_device_start_ip_check (self);
core: fix PropertiesChanged signals for IP-related properties To present a consistent API to clients, the IP-related properties are only valid when the device has finished IP configuration. But they are set before that happens, and their change notifications were emitted before the IP configuration was considered valid. Re-emit the change notifications when the device enters the IP_CHECK state (and thus has IP configuration) and also when the device deactivates to enusre clients have up-to-date IP-related property information. For the changes to has_ip_config(), the priv->ipX_state checks are not necessary since the device will have valid IP configuration when it enters the IP_CHECK state. The other checks can be consolidated into a single statement. Acked-by: Dan Winship
2013-10-09 13:55:05 -05:00
/* IP-related properties are only valid when the device has IP configuration;
* now that it does, ensure their change notifications are emitted.
*/
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
notify_ip_properties (self);
core: ping the gateway during the IP_CHECK state (bgo #702515) Using the new gateway-ping-timeout property, send pings to the first gateway address until it replies or the timeout is reached, to deal with dumb hardware that indicates carrier on but doesn't actually pass traffic. https://bugzilla.gnome.org/show_bug.cgi?id=702515
2013-06-11 17:05:49 -05:00
break;
core: VPN autoconnect feature (bgo #560471) (rh #483120) We go through the SECONDARIES state where we check if there are some secondary (VPN or other) UUIDs that are to be activated before progressing to ACTIVATED. In case of an error with a secondary UUID or its activation, the base connection can't activate successfully.
2012-08-21 17:49:41 +02:00
case NM_DEVICE_STATE_SECONDARIES:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
ip_check_gw_ping_cleanup (self);
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "device entered SECONDARIES state");
core: VPN autoconnect feature (bgo #560471) (rh #483120) We go through the SECONDARIES state where we check if there are some secondary (VPN or other) UUIDs that are to be activated before progressing to ACTIVATED. In case of an error with a secondary UUID or its activation, the base connection can't activate successfully.
2012-08-21 17:49:41 +02:00
break;
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
default:
break;
2005-12-31 Dan Williams <dcbw@redhat.com> * refactor NMDevice into a GObject-based framework with separate objects for wired and wireless. The following files are no longer used but should stick around for a bit so we don't loose code through the cracks: NetworkManagerDevice.c NetworkManagerDevice.h NetworkManagerWireless.c NetworkManagerWireless.h The intent here is to allow each device type to manage its own connection & activation life-cycle, ie to allow wireless devices to interface with wpa_supplicant, etc. There's a fair bit of encapsulation breakage right now that should gradually get pulled back into each device, along with things like periodic property updates and link probing. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1244 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-12-31 08:21:24 +00:00
}
2008-04-27 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-dispatcher-action.c callouts/nm-dispatcher-action.h callouts/nm-dispatcher.conf callouts/nm-dispatcher.xml callouts/org.freedesktop.nm_dispatcher.service - Re-implement the dispatcher as a system-bus activated service that NM calls on-demand, rather than an always running daemon * src/Makefile.am - Add callouts dir to includes to pick up dispatcher defines * src/nm-device.c - (nm_device_state_changed): call dispatcher on device activated/ deactivated * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_set_vpn_state): call dispatcher when VPN connections go up and down * src/NetworkManagerUtils.c src/NetworkManagerUtils.h - (nm_utils_call_dispatcher): helper to call dispatcher git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3607 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-27 14:30:06 +00:00
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
if (state > NM_DEVICE_STATE_DISCONNECTED)
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
delete_on_deactivate_unschedule (self);
core: delete virtual devices created by NM when they are deactivated. Virtual/software devices that were created by NM should be deleted when the device gets deactivated. https://bugzilla.gnome.org/show_bug.cgi?id=695705 https://bugzilla.redhat.com/show_bug.cgi?id=953300 Signed-off-by: Thomas Haller <thaller@redhat.com>
2013-08-07 11:41:40 +02:00
core: implement PRE_DOWN dispatcher actions (bgo #387832) https://bugzilla.gnome.org/show_bug.cgi?id=387832
2014-05-20 17:10:42 -05:00
if ( (old_state == NM_DEVICE_STATE_ACTIVATED || old_state == NM_DEVICE_STATE_DEACTIVATING)
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
&& (state != NM_DEVICE_STATE_DEACTIVATING)) {
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
if (quitting) {
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
nm_dispatcher_call_device_sync (NM_DISPATCHER_ACTION_DOWN,
self, req);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
} else {
core/dispatcher: pass act-request to device dispatcher calls Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based on the settings connection. That is not optimal, because whether a connection is assumed or externally managed, should be really a property of the active-connection. So, in the this will change soon and we would need yet another argument to nm_dispatcher_call(). Instead, drop the settings-connection and applied-connection arguments and fetch them from the device as needed (but allow to pass a specific act-request argument to explicitly state which active connection to use). Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(), it this is not a generic dispatcher call, but it is particularly related to device events. Likewise, rename nm_dispatcher_call_sync() to nm_dispatcher_call_device_sync().
2017-03-08 14:11:22 +01:00
nm_dispatcher_call_device (NM_DISPATCHER_ACTION_DOWN,
self,
req,
NULL, NULL, NULL);
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
}
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
}
2008-04-27 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-dispatcher-action.c callouts/nm-dispatcher-action.h callouts/nm-dispatcher.conf callouts/nm-dispatcher.xml callouts/org.freedesktop.nm_dispatcher.service - Re-implement the dispatcher as a system-bus activated service that NM calls on-demand, rather than an always running daemon * src/Makefile.am - Add callouts dir to includes to pick up dispatcher defines * src/nm-device.c - (nm_device_state_changed): call dispatcher on device activated/ deactivated * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_set_vpn_state): call dispatcher when VPN connections go up and down * src/NetworkManagerUtils.c src/NetworkManagerUtils.h - (nm_utils_call_dispatcher): helper to call dispatcher git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3607 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-27 14:30:06 +00:00
core: fix PropertiesChanged signals for IP-related properties To present a consistent API to clients, the IP-related properties are only valid when the device has finished IP configuration. But they are set before that happens, and their change notifications were emitted before the IP configuration was considered valid. Re-emit the change notifications when the device enters the IP_CHECK state (and thus has IP configuration) and also when the device deactivates to enusre clients have up-to-date IP-related property information. For the changes to has_ip_config(), the priv->ipX_state checks are not necessary since the device will have valid IP configuration when it enters the IP_CHECK state. The other checks can be consolidated into a single statement. Acked-by: Dan Winship
2013-10-09 13:55:05 -05:00
/* IP-related properties are only valid when the device has IP configuration.
* If it no longer does, ensure their change notifications are emitted.
*/
if (ip_config_valid (old_state) && !ip_config_valid (state))
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
notify_ip_properties (self);
core: fix PropertiesChanged signals for IP-related properties To present a consistent API to clients, the IP-related properties are only valid when the device has finished IP configuration. But they are set before that happens, and their change notifications were emitted before the IP configuration was considered valid. Re-emit the change notifications when the device enters the IP_CHECK state (and thus has IP configuration) and also when the device deactivates to enusre clients have up-to-date IP-related property information. For the changes to has_ip_config(), the priv->ipX_state checks are not necessary since the device will have valid IP configuration when it enters the IP_CHECK state. The other checks can be consolidated into a single statement. Acked-by: Dan Winship
2013-10-09 13:55:05 -05:00
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
concheck_periodic_update (self);
2008-04-27 Dan Williams <dcbw@redhat.com> * callouts/Makefile.am callouts/nm-dispatcher-action.c callouts/nm-dispatcher-action.h callouts/nm-dispatcher.conf callouts/nm-dispatcher.xml callouts/org.freedesktop.nm_dispatcher.service - Re-implement the dispatcher as a system-bus activated service that NM calls on-demand, rather than an always running daemon * src/Makefile.am - Add callouts dir to includes to pick up dispatcher defines * src/nm-device.c - (nm_device_state_changed): call dispatcher on device activated/ deactivated * src/vpn-manager/nm-vpn-connection.c - (nm_vpn_connection_set_vpn_state): call dispatcher when VPN connections go up and down * src/NetworkManagerUtils.c src/NetworkManagerUtils.h - (nm_utils_call_dispatcher): helper to call dispatcher git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3607 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-27 14:30:06 +00:00
/* Dispose of the cached activation request */
if (req)
g_object_unref (req);
trivial: warn if we ever re-enter nm_device_state_changed() Motivated by ba48be3a344b64dfb808cb6f3e545829d9884bee.
2012-10-06 12:37:34 -05:00
devices: fix recursive-state-change check nm_device_state_changed() had a check to make sure it wasn't entered recursively (which had been a source of bugs in the past), but it was global rather than per-device, so it caused errors when VLANs changed state in response to their parent device changing state. Fix that. https://bugzilla.gnome.org/show_bug.cgi?id=698619
2013-05-20 16:15:37 -03:00
priv->in_state_changed = FALSE;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
if ((old_state > NM_DEVICE_STATE_UNMANAGED) != (state > NM_DEVICE_STATE_UNMANAGED))
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
_notify (self, PROP_MANAGED);
2007-02-05 Tambet Ingo <tambet@ximian.com> Make NMDevice abstract class, remove almost all references to it's subclasses (the last place gets removed with new policy manager). Add NMDeviceInterface (which NMDevice implements) so that when we have NMDevice exported over DBUS, there's a common NMDevice interface which all instances have, plus there's a device specific interface for each specific type. Remove functions (nm_device_is_802_3_ethernet) and (nm_device_is_802_11_wireless). There are already standard GObject macros for type safe checks. Use the updated supplican manager API. * src/nm-device-interface.h: * src/nm-device-interface.c: * src/nm-call-store.h: * src/nm-call-store.c: Implement. * src/supplicant-manager/nm-supplicant-interface.c: * src/supplicant-manager/nm-supplicant-interface.h: * src/supplicant-manager/nm-supplicant-manager.c: * src/supplicant-manager/nm-supplicant-manager.h: - Remove all private data type references from public header files. - Remove all references to other NM classes, this class is just a proxy between wpa_supplicant and NM so it doesn't have to know any internals. - Convert to dbus-glib bindings. - Type safe checks for public methods' arguments. - Store pending DBUS call ids to NMCallStore. * src/supplicant-manager/nm-supplicant-config.c: - Store config values in a GHashTable instead of GSList. git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@2285 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2007-02-05 12:14:09 +00:00
}
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
void
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_state_changed (NMDevice *self,
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
NMDeviceState state,
NMDeviceStateReason reason)
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
_set_state_full (self, state, reason, FALSE);
core: block on dispatcher scripts when quitting Like VPN connections, block on dispatcher scripts when quitting. Since the event loop is no longer running we can't schedule callbacks.
2014-05-23 18:25:05 -05:00
}
core: add generic queued state transitions There are now three places we need delayed state transitions: 1) unavailable to disconnected 2) failed to disconnected 3) bond unavailable to disconnected (3) wasn't doing a delayed transition, but we can't change state from inside a state-change handler otherwise we may not end up fully processing the current state chagne. So it needs a delayed transition too; add some generic code to make that easier to do.
2011-12-08 11:46:58 -06:00
static gboolean
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
queued_state_set (gpointer user_data)
core: add generic queued state transitions There are now three places we need delayed state transitions: 1) unavailable to disconnected 2) failed to disconnected 3) bond unavailable to disconnected (3) wasn't doing a delayed transition, but we can't change state from inside a state-change handler otherwise we may not end up fully processing the current state chagne. So it needs a delayed transition too; add some generic code to make that easier to do.
2011-12-08 11:46:58 -06:00
{
NMDevice *self = NM_DEVICE (user_data);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: allow state change queuing from inside queued state handler Clear the queued state struct before triggering the state change, instead of after, since the state change may queue another state change.
2012-11-14 18:00:22 -06:00
NMDeviceState new_state;
NMDeviceStateReason new_reason;
core: add generic queued state transitions There are now three places we need delayed state transitions: 1) unavailable to disconnected 2) failed to disconnected 3) bond unavailable to disconnected (3) wasn't doing a delayed transition, but we can't change state from inside a state-change handler otherwise we may not end up fully processing the current state chagne. So it needs a delayed transition too; add some generic code to make that easier to do.
2011-12-08 11:46:58 -06:00
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
nm_assert (priv->queued_state.id);
core: allow state change queuing from inside queued state handler Clear the queued state struct before triggering the state change, instead of after, since the state change may queue another state change.
2012-11-14 18:00:22 -06:00
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
_LOGD (LOGD_DEVICE, "queue-state[%s, reason:%s, id:%u]: %s",
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (priv->queued_state.state),
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
reason_to_string (priv->queued_state.reason),
priv->queued_state.id,
"change state");
core: allow state change queuing from inside queued state handler Clear the queued state struct before triggering the state change, instead of after, since the state change may queue another state change.
2012-11-14 18:00:22 -06:00
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
/* Clear queued state struct before triggering state change, since
* the state change may queue another state.
*/
priv->queued_state.id = 0;
new_state = priv->queued_state.state;
new_reason = priv->queued_state.reason;
nm_device_state_changed (self, new_state, new_reason);
nm_device_remove_pending_action (self, queued_state_to_string (new_state), TRUE);
return G_SOURCE_REMOVE;
core: add generic queued state transitions There are now three places we need delayed state transitions: 1) unavailable to disconnected 2) failed to disconnected 3) bond unavailable to disconnected (3) wasn't doing a delayed transition, but we can't change state from inside a state-change handler otherwise we may not end up fully processing the current state chagne. So it needs a delayed transition too; add some generic code to make that easier to do.
2011-12-08 11:46:58 -06:00
}
void
nm_device_queue_state (NMDevice *self,
NMDeviceState state,
NMDeviceStateReason reason)
{
NMDevicePrivate *priv;
g_return_if_fail (NM_IS_DEVICE (self));
priv = NM_DEVICE_GET_PRIVATE (self);
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
if (priv->queued_state.id && priv->queued_state.state == state) {
_LOGD (LOGD_DEVICE, "queue-state[%s, reason:%s, id:%u]: %s%s%s%s",
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (priv->queued_state.state),
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
reason_to_string (priv->queued_state.reason),
priv->queued_state.id,
"ignore queuing same state change",
NM_PRINT_FMT_QUOTED (priv->queued_state.reason != reason,
" (reason differs: ", reason_to_string (reason), ")", ""));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
return;
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
}
core: add IP configuration for unmanaged devices Use NMPlatform to read the IP address/route configuration of unmanaged devices, and export that via D-Bus like we do with NM-generated IP configs.
2013-04-04 10:20:24 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Add pending action for the new state before clearing the queued states, so
* that we don't accidently pop all pending states and reach 'startup complete' */
nm_device_add_pending_action (self, queued_state_to_string (state), TRUE);
core: capture initial device DHCP IP configuration At least gives us DNS servers and definite gateway.
2013-11-02 10:38:23 -05:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* We should only ever have one delayed state transition at a time */
if (priv->queued_state.id) {
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
_LOGW (LOGD_DEVICE, "queue-state[%s, reason:%s, id:%u]: %s",
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (priv->queued_state.state),
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
reason_to_string (priv->queued_state.reason),
priv->queued_state.id,
"replace previously queued state change");
nm_clear_g_source (&priv->queued_state.id);
nm_device_remove_pending_action (self, queued_state_to_string (priv->queued_state.state), TRUE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
core: add IP configuration for unmanaged devices Use NMPlatform to read the IP address/route configuration of unmanaged devices, and export that via D-Bus like we do with NM-generated IP configs.
2013-04-04 10:20:24 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv->queued_state.state = state;
priv->queued_state.reason = reason;
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
priv->queued_state.id = g_idle_add (queued_state_set, self);
core: add IP configuration for unmanaged devices Use NMPlatform to read the IP address/route configuration of unmanaged devices, and export that via D-Bus like we do with NM-generated IP configs.
2013-04-04 10:20:24 -04:00
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
_LOGD (LOGD_DEVICE, "queue-state[%s, reason:%s, id:%u]: %s",
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (state),
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
reason_to_string (reason),
priv->queued_state.id,
"queue state change");
core: add IP configuration for unmanaged devices Use NMPlatform to read the IP address/route configuration of unmanaged devices, and export that via D-Bus like we do with NM-generated IP configs.
2013-04-04 10:20:24 -04:00
}
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
static void
queued_state_clear (NMDevice *self)
core: add IP configuration for unmanaged devices Use NMPlatform to read the IP address/route configuration of unmanaged devices, and export that via D-Bus like we do with NM-generated IP configs.
2013-04-04 10:20:24 -04:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
if (!priv->queued_state.id)
return;
_LOGD (LOGD_DEVICE, "queue-state[%s, reason:%s, id:%u]: %s",
device: expose nm_device_state_to_str() function for NMDeviceState
2017-06-07 17:22:16 +02:00
nm_device_state_to_str (priv->queued_state.state),
device: cleanup handling queued state change in NMDevice - no longer bother clearing .state and .reason when the .id field is unset. The fields just don't matter and no user accesses these fields when the glib source id is not set. - unify logging and give them all a prefix "queue-state[%s, %s, %u]: ". - drop nm_device_queued_state_peek(), it only had one caller, thus inline the trivial check. - make nm_device_queued_state_clear() a static function queued_state_clear() - rename queued_set_state() to queued_state_set().
2017-02-02 12:39:07 +01:00
reason_to_string (priv->queued_state.reason),
priv->queued_state.id,
"clear queued state change");
nm_clear_g_source (&priv->queued_state.id);
nm_device_remove_pending_action (self, queued_state_to_string (priv->queued_state.state), TRUE);
core: add IP configuration for unmanaged devices Use NMPlatform to read the IP address/route configuration of unmanaged devices, and export that via D-Bus like we do with NM-generated IP configs.
2013-04-04 10:20:24 -04:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
NMDeviceState
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_get_state (NMDevice *self)
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
{
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), NM_DEVICE_STATE_UNKNOWN);
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
return NM_DEVICE_GET_PRIVATE (self)->state;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* NMConfigDevice interface related stuff */
core: convert unmanaged bits to flags Instead of tracking unmanaged-ness in a couple variables (and because I'd like to add one for user-unmanaged later) let's do it in a single flags variable, and consolidate setting of the unmanaged states in one place.
2014-03-31 21:45:54 -05:00
core: update data types of some hwaddr properties Now that we have nm_utils_hwaddr_matches() for comparing addresses (even when one is a string and the other binary), there are now places where it's more convenient to store hardware addresses as strings rather than binary, since we want them in string form for most non-comparison purposes. So update for that. In particular, this also changes nm_device_get_hw_address() to return a string. Also, simplify the update_permanent_hw_address() implementations by assuming that they will only be called once. (Since they will.)
2014-06-21 12:44:56 -04:00
const char *
nm_device_get_hw_address (NMDevice *self)
core: add a "default-unmanaged" setting for devices Allow devices to declare themselves unmanaged-by-default, but tweak nm-manager and nm-policy to allow activating matching connections on those devices anyway. (This ensures that NM keeps its hands completely off the device unless the user explicitly asks it to do something with it.)
2013-04-24 10:40:58 -04:00
{
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
NMDevicePrivate *priv;
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
char buf[NM_UTILS_HWADDR_LEN_MAX];
gsize l;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
nm_assert ( (!priv->hw_addr && priv->hw_addr_len == 0)
|| ( priv->hw_addr
&& _nm_utils_hwaddr_aton (priv->hw_addr, buf, sizeof (buf), &l)
&& l == priv->hw_addr_len));
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
return priv->hw_addr;
core: convert unmanaged bits to flags Instead of tracking unmanaged-ness in a couple variables (and because I'd like to add one for user-unmanaged later) let's do it in a single flags variable, and consolidate setting of the unmanaged states in one place.
2014-03-31 21:45:54 -05:00
}
Clarify comments and clean up some code git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3588 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-22 19:07:00 +00:00
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_update_hw_address (NMDevice *self)
core: convert unmanaged bits to flags Instead of tracking unmanaged-ness in a couple variables (and because I'd like to add one for user-unmanaged later) let's do it in a single flags variable, and consolidate setting of the unmanaged states in one place.
2014-03-31 21:45:54 -05:00
{
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
NMDevicePrivate *priv;
core: simplify hardware address reading We no longer need a class method for reading the hardware address length, for a couple reasons: 1) Using the IP interface hardware address for IP operations now makes NMDevice's priv->hw_addr_len constant. So there's no reason to re-read it all the time. 2) get_hw_address_length() is now only used for determining whether the hardware address is permanent, and that only mattered for Bluetooth. Since Bluetooth interfaces have a bogus interface name, they will never have a valid ifindex, and thus nm_platform_link_get_address() would be useless. So instead of using the 'permanent' stuff, just don't bother updating the hardware address if the NMDevice's ifindex isn't valid, and let subclasses pass the initial hardware address at device creation. This also works correctly for NMDevice classes that previously implemented get_hw_address_length() like ADSL and WWAN, since those too will never have a valid ifindex or a valid hardware address. 3) Reading the device's hardware address length just ended up calling nm_platform_link_get_address() for most devices anyway, so nm_device_update_hw_address() would effectively read the link address twice (once to read the length, the second time to read the actual address). Let's just read the address once.
2014-07-14 17:59:45 -05:00
const guint8 *hwaddr;
gsize hwaddrlen = 0;
2008-04-07 Dan Williams <dcbw@redhat.com> * include/NetworkManager.h - Remove the DOWN and CANCELLED device states - Add UNMANAGED and UNAVAILABLE device states - Document the device states * introspection/nm-device.xml src/nm-device-interface.c src/nm-device-interface.h - Add the 'managed' property * test/nm-tool.c - (detail_device): print out device state * src/NetworkManagerSystem.h src/backends/NetworkManagerArch.c src/backends/NetworkManagerDebian.c src/backends/NetworkManagerFrugalware.c src/backends/NetworkManagerGentoo.c src/backends/NetworkManagerMandriva.c src/backends/NetworkManagerPaldo.c src/backends/NetworkManagerRedHat.c src/backends/NetworkManagerSlackware.c src/backends/NetworkManagerSuSE.c - (nm_system_device_get_system_config, nm_system_device_get_disabled nm_system_device_free_system_config): remove; they were unused and their functionality should be re-implemented in each distro's system settings service plugin * src/nm-gsm-device.c src/nm-gsm-device.h src/nm-cdma-device.c src/nm-cdma-device.h - (*_new): take the 'managed' argument * src/nm-device.c - (nm_device_set_address): remove, fold into nm_device_bring_up() - (nm_device_init): start in unmanaged state, not disconnected - (constructor): don't start device until the system settings service has had a chance to figure out if the device is managed or not - (nm_device_deactivate, nm_device_bring_up, nm_device_bring_down): don't set device state here, let callers handle that as appropriate - (nm_device_dispose): don't touch the device if it's not managed - (set_property, get_property, nm_device_class_init): implement the 'managed' property - (nm_device_state_changed): bring the device up if its now managed, and deactivate it if it used to be active - (nm_device_get_managed, nm_device_set_managed): do the right thing with the managed state * src/nm-hal-manager.c - (wired_device_creator, wireless_device_creator, modem_device_creator): take initial managed state and pass it along to device constructors - (create_device_and_add_to_list): get managed state and pass to type creators * src/nm-device-802-11-wireless.c - (real_can_activate): fold in most of nm_device_802_11_wireless_can_activate() - (can_scan): can't scan in UNAVAILABLE or UNMANAGED - (link_timeout_cb): instead of deactivating, change device state and let the device state handler to it - (real_update_hw_address): clean up - (state_changed_cb): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device isn't rfkilled * src/nm-device-802-3-ethernet.c - (set_carrier): move above callers and get rid of prototype - (device_state_changed): when entering UNAVAILABLE state, schedule an idle handler to transition to DISCONNECTED if the device has a carrier - (real_update_hw_address): clean up - (link_timeout_cb, ppp_state_changed): change state instead of calling deactivation directly as deactivation doesn't change state anymore * src/NetworkManagerPolicy.c - (schedule_activate_check): yay, remove wireless_enabled hack since the NMManager and wireless devices work that out themselves now - (device_state_changed): change to a switch and update for new device states - (device_carrier_changed): remove; device handles this now through state changes - (device_added): don't care about carrier any more; the initial activation check will happen when the device transitions to DISCONNECTED * src/nm-manager.c - (dispose): clear unmanaged devices - (handle_unmanaged_devices): update unmanaged device list and toggle the managed property on each device when needed - (system_settings_properties_changed_cb): handle signals from the system settings service - (system_settings_get_unmanaged_devices_cb): handle callback from getting the unmanaged device list method call - (query_unmanaged_devices): ask the system settings service for its list of unmanaged devices - (nm_manager_name_owner_changed, initial_get_connections): get unmanaged devices - (manager_set_wireless_enabled): push rfkill state down to wireless devices directly and let them handle the necessary state transitions - (manager_device_state_changed): update for new device states - (nm_manager_add_device): set initial rfkill state on wireless devices - (nm_manager_remove_device): don't touch the device if it's unmanaged - (nm_manager_activate_connection): return error if the device is unmanaged - (nm_manager_sleep): handle new device states correctly; don't change the state of unavailable/unmanaged devices * libnm-glib/nm-device-802-11-wireless.c - (state_changed_cb): update for new device states git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3540 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2008-04-08 02:58:02 +00:00
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
device: only set permanent hardware address once While a device is realized, we only want to read the permanent MAC address once. If that fails, we fallback to the current MAC address. Thus, we want the permanent address be stable until the device unrealizes. While we want to fallback to the current MAC address, in some cases the caller wants to know whether this was a "real" permanent MAC address as read via ethtool. For example, when matching an ethernet device against ethernet.mac-address property, the fake (current) address should not be used in such case.
2016-05-20 13:47:23 +02:00
if (priv->ifindex <= 0)
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
return FALSE;
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
hwaddr = nm_platform_link_get_address (nm_device_get_platform (self), priv->ifindex, &hwaddrlen);
device: drop leftover bad assert NetworkManager:ERROR:devices/nm-device.c:7089:nm_device_update_hw_address: assertion failed: (hwaddrlen <= sizeof (priv->hw_addr)) Aborted (core dumped) Breaks 32-bit, works on 64-bit by dumb luck. https://bugzilla.gnome.org/show_bug.cgi?id=737900 Fixes: b019348fdde223f39c91150e6b7a11e366fade63 Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-10-04 15:59:37 +02:00
device: wait for valid MAC before making ethernet devices available In certain situations, ethernet links first appear with a zero MAC address and then the MAC changes some time later. Currently NM does not deal correctly with this scenario since it initializes wrong @initial_hwaddr and @permanent_hwaddr on the device and tries to immediately activate it. To fix this, initialize the device's addresses only when the MAC becomes valid and make the device available only at that point.
2015-12-13 22:09:59 +01:00
if ( priv->type == NM_DEVICE_TYPE_ETHERNET
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
&& hwaddr
device: replace static zero_hwaddr by nm_ip_addr_zero.addr_eth Instead of defining multiple all-zero-ethernet-address variables, use nm_ip_addr_zero.addr_eth.
2016-05-24 11:28:44 +02:00
&& nm_utils_hwaddr_matches (hwaddr, hwaddrlen, nm_ip_addr_zero.addr_eth, sizeof (nm_ip_addr_zero.addr_eth)))
device: wait for valid MAC before making ethernet devices available In certain situations, ethernet links first appear with a zero MAC address and then the MAC changes some time later. Currently NM does not deal correctly with this scenario since it initializes wrong @initial_hwaddr and @permanent_hwaddr on the device and tries to immediately activate it. To fix this, initialize the device's addresses only when the MAC becomes valid and make the device available only at that point.
2015-12-13 22:09:59 +01:00
hwaddrlen = 0;
device: suppress log message in nm_device_update_hw_address() when no MAC address For example for tun devices we get a lot of (tun7): hw-addr: failed reading current MAC address warnings. Just be silent about it. We log when something changes, we don't need to log when we fail to obtain a MAC address. Thereby, refactor nm_device_update_hw_address() to return early.
2016-10-28 17:06:13 +02:00
if (!hwaddrlen)
return FALSE;
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
device: suppress log message in nm_device_update_hw_address() when no MAC address For example for tun devices we get a lot of (tun7): hw-addr: failed reading current MAC address warnings. Just be silent about it. We log when something changes, we don't need to log when we fail to obtain a MAC address. Thereby, refactor nm_device_update_hw_address() to return early.
2016-10-28 17:06:13 +02:00
if ( priv->hw_addr_len
&& priv->hw_addr_len != hwaddrlen) {
char s_buf[NM_UTILS_HWADDR_LEN_MAX_STR];
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
device: suppress log message in nm_device_update_hw_address() when no MAC address For example for tun devices we get a lot of (tun7): hw-addr: failed reading current MAC address warnings. Just be silent about it. We log when something changes, we don't need to log when we fail to obtain a MAC address. Thereby, refactor nm_device_update_hw_address() to return early.
2016-10-28 17:06:13 +02:00
/* we cannot change the address length of a device once it is set (except
* unrealizing the device).
*
* The reason is that the permanent and initial MAC addresses also must have the
* same address length, so it's unclear what it would mean that the length changes. */
_LOGD (LOGD_PLATFORM | LOGD_DEVICE,
"hw-addr: read a MAC address with differing length (%s vs. %s)",
priv->hw_addr,
nm_utils_hwaddr_ntoa_buf (hwaddr, hwaddrlen, TRUE, s_buf, sizeof (s_buf)));
return FALSE;
}
core: convert unmanaged bits to flags Instead of tracking unmanaged-ness in a couple variables (and because I'd like to add one for user-unmanaged later) let's do it in a single flags variable, and consolidate setting of the unmanaged states in one place.
2014-03-31 21:45:54 -05:00
device: suppress log message in nm_device_update_hw_address() when no MAC address For example for tun devices we get a lot of (tun7): hw-addr: failed reading current MAC address warnings. Just be silent about it. We log when something changes, we don't need to log when we fail to obtain a MAC address. Thereby, refactor nm_device_update_hw_address() to return early.
2016-10-28 17:06:13 +02:00
if ( priv->hw_addr
&& nm_utils_hwaddr_matches (priv->hw_addr, -1, hwaddr, hwaddrlen))
return FALSE;
device: re-read the current MAC address when the link changes The current MAC address is part of NMPlatformLink in the platform cache. When it changes, we must update the device's current value. Also, the MAC address of NMDeviceEthernet is exposed on D-Bus. That property should show the currently configured MAC address, not a state that was read some time in the past. Also, nm_device_hw_addr_set() compares the current MAC address before resetting it. If that field is out-of-date, nm_device_hw_addr_set() will behave wrongly. NMDeviceEthernet had some special handling in link_changed() that would re-read the MAC addresses and possibly bring up the interface. Move that code to the parent device.
2016-05-24 13:45:58 +02:00
device: suppress log message in nm_device_update_hw_address() when no MAC address For example for tun devices we get a lot of (tun7): hw-addr: failed reading current MAC address warnings. Just be silent about it. We log when something changes, we don't need to log when we fail to obtain a MAC address. Thereby, refactor nm_device_update_hw_address() to return early.
2016-10-28 17:06:13 +02:00
g_free (priv->hw_addr);
priv->hw_addr_len_ = hwaddrlen;
priv->hw_addr = nm_utils_hwaddr_ntoa (hwaddr, hwaddrlen);
_LOGD (LOGD_PLATFORM | LOGD_DEVICE, "hw-addr: hardware address now %s", priv->hw_addr);
_notify (self, PROP_HW_ADDRESS);
if ( !priv->hw_addr_initial
|| ( priv->hw_addr_type == HW_ADDR_TYPE_UNSET
&& priv->state < NM_DEVICE_STATE_PREPARE
&& !nm_device_is_activating (self))) {
/* when we get a hw_addr the first time or while the device
* is not activated (with no explict hw address set), always
* update our inital hw-address as well. */
nm_device_update_initial_hw_address (self);
core: convert unmanaged bits to flags Instead of tracking unmanaged-ness in a couple variables (and because I'd like to add one for user-unmanaged later) let's do it in a single flags variable, and consolidate setting of the unmanaged states in one place.
2014-03-31 21:45:54 -05:00
}
device: suppress log message in nm_device_update_hw_address() when no MAC address For example for tun devices we get a lot of (tun7): hw-addr: failed reading current MAC address warnings. Just be silent about it. We log when something changes, we don't need to log when we fail to obtain a MAC address. Thereby, refactor nm_device_update_hw_address() to return early.
2016-10-28 17:06:13 +02:00
return TRUE;
core: add a "default-unmanaged" setting for devices Allow devices to declare themselves unmanaged-by-default, but tweak nm-manager and nm-policy to allow activating matching connections on those devices anyway. (This ensures that NM keeps its hands completely off the device unless the user explicitly asks it to do something with it.)
2013-04-24 10:40:58 -04:00
}
device: wait for valid MAC before making ethernet devices available In certain situations, ethernet links first appear with a zero MAC address and then the MAC changes some time later. Currently NM does not deal correctly with this scenario since it initializes wrong @initial_hwaddr and @permanent_hwaddr on the device and tries to immediately activate it. To fix this, initialize the device's addresses only when the MAC becomes valid and make the device available only at that point.
2015-12-13 22:09:59 +01:00
void
device/trivial: split out nm_device_update_initial_hw_address()
2015-12-14 08:46:29 +01:00
nm_device_update_initial_hw_address (NMDevice *self)
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: cleanup logging for setting MAC address Give all related messages a "set-hw-addr"/"hw-addr" prefix.
2016-05-20 13:36:09 +02:00
if ( priv->hw_addr
device/trivial: rename hw-addr related fields in NMDevicePrivate Next I will add two more fields. Being able to efficiently grep the code is important. I want to be able to grep for "->hw_addr" or "\<hw_addr" to find related stuff. Unfortunately, prefixes often result in backward English names, e.g. hw_addr_set/hw_addr_get. I still prefer that over get_hw_addr/set_hw_addr though.
2016-06-03 13:37:08 +02:00
&& !nm_streq0 (priv->hw_addr_initial, priv->hw_addr)) {
wifi: implement MAC address randomization in NetworkManager instead of supplicant 'wireless.mac-address-randomization' broke 'wireless.cloned-mac-address', because we would always set 'PreassocMacAddr=1'. The reason is that supplicant would set 'wpa_s->mac_addr_changed' during scanning, and later during association it would either set a random MAC address or reset the permanent MAC address [1]. Anyway, 'wireless.mac-address-randomization' conflicts with 'wireless.cloned-mac-address'. Instead of letting supplicant set the MAC address, manage the MAC addresses entirely from NetworkManager. Supplicant should not touch it. [1] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=f885b8e97cf39b56fe7ca6577890f2d20df7ae08#n1663
2016-06-20 12:28:04 +02:00
if ( priv->hw_addr_initial
&& priv->hw_addr_type != HW_ADDR_TYPE_UNSET) {
/* once we have the initial hw address set, we only allow
* update if the currenty type is "unset". */
return;
}
device/trivial: rename hw-addr related fields in NMDevicePrivate Next I will add two more fields. Being able to efficiently grep the code is important. I want to be able to grep for "->hw_addr" or "\<hw_addr" to find related stuff. Unfortunately, prefixes often result in backward English names, e.g. hw_addr_set/hw_addr_get. I still prefer that over get_hw_addr/set_hw_addr though.
2016-06-03 13:37:08 +02:00
g_free (priv->hw_addr_initial);
priv->hw_addr_initial = g_strdup (priv->hw_addr);
device: cleanup logging for setting MAC address Give all related messages a "set-hw-addr"/"hw-addr" prefix.
2016-05-20 13:36:09 +02:00
_LOGD (LOGD_DEVICE, "hw-addr: update initial MAC address %s",
device/trivial: rename hw-addr related fields in NMDevicePrivate Next I will add two more fields. Being able to efficiently grep the code is important. I want to be able to grep for "->hw_addr" or "\<hw_addr" to find related stuff. Unfortunately, prefixes often result in backward English names, e.g. hw_addr_set/hw_addr_get. I still prefer that over get_hw_addr/set_hw_addr though.
2016-06-03 13:37:08 +02:00
priv->hw_addr_initial);
device: split nm_device_update_permanent_hw_address() out of nm_device_update_initial_hw_address() Either, the function is called different to reflect that it does not only update the initial_hw_addres, or it is split. Split it.
2016-05-20 13:33:28 +02:00
}
}
device/trivial: split out nm_device_update_initial_hw_address()
2015-12-14 08:46:29 +01:00
device: split nm_device_update_permanent_hw_address() out of nm_device_update_initial_hw_address() Either, the function is called different to reflect that it does not only update the initial_hw_addres, or it is split. Split it.
2016-05-20 13:33:28 +02:00
void
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
nm_device_update_permanent_hw_address (NMDevice *self, gboolean force_freeze)
device: split nm_device_update_permanent_hw_address() out of nm_device_update_initial_hw_address() Either, the function is called different to reflect that it does not only update the initial_hw_addres, or it is split. Split it.
2016-05-20 13:33:28 +02:00
{
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: only set permanent hardware address once While a device is realized, we only want to read the permanent MAC address once. If that fails, we fallback to the current MAC address. Thus, we want the permanent address be stable until the device unrealizes. While we want to fallback to the current MAC address, in some cases the caller wants to know whether this was a "real" permanent MAC address as read via ethtool. For example, when matching an ethernet device against ethernet.mac-address property, the fake (current) address should not be used in such case.
2016-05-20 13:47:23 +02:00
guint8 buf[NM_UTILS_HWADDR_LEN_MAX];
size_t len = 0;
gboolean success_read;
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
int ifindex;
const NMPlatformLink *pllink;
device: split nm_device_update_permanent_hw_address() out of nm_device_update_initial_hw_address() Either, the function is called different to reflect that it does not only update the initial_hw_addres, or it is split. Split it.
2016-05-20 13:33:28 +02:00
device: only set permanent hardware address once While a device is realized, we only want to read the permanent MAC address once. If that fails, we fallback to the current MAC address. Thus, we want the permanent address be stable until the device unrealizes. While we want to fallback to the current MAC address, in some cases the caller wants to know whether this was a "real" permanent MAC address as read via ethtool. For example, when matching an ethernet device against ethernet.mac-address property, the fake (current) address should not be used in such case.
2016-05-20 13:47:23 +02:00
if (priv->hw_addr_perm) {
/* the permanent hardware address is only read once and not
* re-read later.
*
* Except during unrealize/realize cycles, where we clear the permanent
* hardware address during unrealization. */
return;
}
device/trivial: split out nm_device_update_initial_hw_address()
2015-12-14 08:46:29 +01:00
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
ifindex = priv->ifindex;
if (ifindex <= 0)
device: only set permanent hardware address once While a device is realized, we only want to read the permanent MAC address once. If that fails, we fallback to the current MAC address. Thus, we want the permanent address be stable until the device unrealizes. While we want to fallback to the current MAC address, in some cases the caller wants to know whether this was a "real" permanent MAC address as read via ethtool. For example, when matching an ethernet device against ethernet.mac-address property, the fake (current) address should not be used in such case.
2016-05-20 13:47:23 +02:00
return;
device: don't use g_warning for differing hw-addr-len after reading permanent address Accessing the platform cache might anytime yield unexpected results. E.g. the link could be gone, or the ifindex could even be replaced by a different interface (yes, that can happen when moving links between network namespaces). It's not clear how to handle such a case at runtime. It seems wrong to me to just error out. Still, such case might happen under normal conditions, so it's wrong to just warn and proceed.
2016-05-20 10:09:39 +02:00
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
/* the user is advised to configure stable MAC addresses for software devices via
* UDEV. Thus, check whether the link is fully initialized. */
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
pllink = nm_platform_link_get (nm_device_get_platform (self), ifindex);
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
if ( !pllink
|| !pllink->initialized) {
if (!force_freeze) {
/* we can afford to wait. Back off and leave the permanent MAC address
* undecided for now. */
device: only set permanent hardware address once While a device is realized, we only want to read the permanent MAC address once. If that fails, we fallback to the current MAC address. Thus, we want the permanent address be stable until the device unrealizes. While we want to fallback to the current MAC address, in some cases the caller wants to know whether this was a "real" permanent MAC address as read via ethtool. For example, when matching an ethernet device against ethernet.mac-address property, the fake (current) address should not be used in such case.
2016-05-20 13:47:23 +02:00
return;
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
}
/* try to refresh the link just to give UDEV a bit more time... */
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
nm_platform_link_refresh (nm_device_get_platform (self), ifindex);
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
/* maybe the MAC address changed... */
nm_device_update_hw_address (self);
} else if (!priv->hw_addr_len)
nm_device_update_hw_address (self);
if (!priv->hw_addr_len) {
/* we need the current MAC address because we require the permanent MAC address
* to have the same length as the current address.
*
* Abort if there is no current MAC address. */
return;
}
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
success_read = nm_platform_link_get_permanent_address (nm_device_get_platform (self), ifindex, buf, &len);
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
if (success_read && priv->hw_addr_len == len) {
priv->hw_addr_perm_fake = FALSE;
priv->hw_addr_perm = nm_utils_hwaddr_ntoa (buf, len);
_LOGD (LOGD_DEVICE, "hw-addr: read permanent MAC address '%s'",
priv->hw_addr_perm);
goto notify_and_out;
device: only set permanent hardware address once While a device is realized, we only want to read the permanent MAC address once. If that fails, we fallback to the current MAC address. Thus, we want the permanent address be stable until the device unrealizes. While we want to fallback to the current MAC address, in some cases the caller wants to know whether this was a "real" permanent MAC address as read via ethtool. For example, when matching an ethernet device against ethernet.mac-address property, the fake (current) address should not be used in such case.
2016-05-20 13:47:23 +02:00
}
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
/* we failed to read a permanent MAC address, thus we use a fake address,
* that is the current MAC address of the device.
*
* Note that the permanet MAC address of a NMDevice instance does not change
* after being set once. Thus, we use now a fake address and stick to that
* (until we unrealize the device). */
priv->hw_addr_perm_fake = TRUE;
/* We also persist our choice of the fake address to the device state
* file to use the same address on restart of NetworkManager.
* First, try to reload the address from the state file. */
{
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
gs_free NMConfigDeviceStateData *dev_state = NULL;
config: remove unused NMConfig self argument from nm_config_device_state_*() API nm_config_device_state_*() always access the file system directly, they don't cache data in NMConfig. Hence, they don't use the @self argument. Maybe those functions don't belong to nm-config.h, anyway. For lack of a better place they are there.
2017-04-19 15:45:31 +02:00
dev_state = nm_config_device_state_load (ifindex);
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
if ( dev_state
&& dev_state->perm_hw_addr_fake
&& nm_utils_hwaddr_aton (dev_state->perm_hw_addr_fake, buf, priv->hw_addr_len)
&& !nm_utils_hwaddr_matches (buf, priv->hw_addr_len, priv->hw_addr, -1)) {
_LOGD (LOGD_PLATFORM | LOGD_ETHER, "hw-addr: %s (use from statefile: %s, current: %s)",
success_read
? "read HW addr length of permanent MAC address differs"
: "unable to read permanent MAC address",
dev_state->perm_hw_addr_fake,
priv->hw_addr);
priv->hw_addr_perm = nm_utils_hwaddr_ntoa (buf, priv->hw_addr_len);
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
goto notify_and_out;
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
}
device/trivial: split out nm_device_update_initial_hw_address()
2015-12-14 08:46:29 +01:00
}
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
_LOGD (LOGD_PLATFORM | LOGD_ETHER, "hw-addr: %s (use current: %s)",
success_read
? "read HW addr length of permanent MAC address differs"
: "unable to read permanent MAC address",
priv->hw_addr);
priv->hw_addr_perm = g_strdup (priv->hw_addr);
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
notify_and_out:
device: implememnt "perm-hw-address" property in NMDevice Both NMDeviceEthernet and NMDeviceWifi have a property "perm-hw-address". As the hw_addr_perm property is tracked in the parent NMDevice class, let it also implement the GObject property. Then it knows better when to emit a notification about property changes.
2016-06-17 18:53:45 +02:00
_notify (self, PROP_PERM_HW_ADDRESS);
device/trivial: split out nm_device_update_initial_hw_address()
2015-12-14 08:46:29 +01:00
}
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
static const char *
_get_cloned_mac_address_setting (NMDevice *self, NMConnection *connection, gboolean is_wifi, char **out_addr)
{
NMSetting *setting;
const char *addr = NULL;
nm_assert (out_addr && !*out_addr);
setting = nm_connection_get_setting (connection,
is_wifi ? NM_TYPE_SETTING_WIRELESS : NM_TYPE_SETTING_WIRED);
if (setting) {
addr = is_wifi
? nm_setting_wireless_get_cloned_mac_address ((NMSettingWireless *) setting)
: nm_setting_wired_get_cloned_mac_address ((NMSettingWired *) setting);
}
if (!addr) {
gs_free char *a = NULL;
a = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
is_wifi ? "wifi.cloned-mac-address" : "ethernet.cloned-mac-address",
self);
device: change default value for cloned-mac-address to "preserve" (bgo#770611) Long ago before commit 1b49f94, NetworkManager did not touch the MAC address at all. Since 0.8.2 NetworkManager would modify the MAC address, and eventually it would reset the permanent MAC address of the device. This prevents a user from externally setting the MAC address via tools like macchanger and rely on NetworkManager not to reset it to the permanent MAC address. This is considered a security regression in bgo#708820. This only changed with commit 9a354cd and 1.4.0. Since then it is possible to configure "cloned-mac-address=preserve", which instead uses the "initial" MAC address when the device activates. That also changed that the "initial" MAC address is the address which was externally configured on the device as last. In other words, the "initial" MAC address is picked up from external changes, unless it was NetworkManager itself who configured the address when activating a connection. However, in absence of an explicit configuration the default for "cloned-mac-address" is still "permanent". Meaning, the user has to explicitly configure that NetworkManager should not touch the MAC address. It makes sense to change the upstream default to "preserve". Although this is a change in behavior since 0.8.2, it seems a better default. This change has the drastic effect that all the existing connections out there with "cloned-mac-address=$(nil)" change behavior after upgrade. I think most users won't notice, because their devices have the permanent address set by default anyway. I would think that there are few users who intentionally configured "cloned-mac-address=" to have NetworkManager restore the permanent address. https://bugzilla.gnome.org/show_bug.cgi?id=770611
2016-09-01 16:18:34 +02:00
addr = NM_CLONED_MAC_PRESERVE;
wifi: implement MAC address randomization in NetworkManager instead of supplicant 'wireless.mac-address-randomization' broke 'wireless.cloned-mac-address', because we would always set 'PreassocMacAddr=1'. The reason is that supplicant would set 'wpa_s->mac_addr_changed' during scanning, and later during association it would either set a random MAC address or reset the permanent MAC address [1]. Anyway, 'wireless.mac-address-randomization' conflicts with 'wireless.cloned-mac-address'. Instead of letting supplicant set the MAC address, manage the MAC addresses entirely from NetworkManager. Supplicant should not touch it. [1] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=f885b8e97cf39b56fe7ca6577890f2d20df7ae08#n1663
2016-06-20 12:28:04 +02:00
if (!a) {
if (is_wifi) {
NMSettingMacRandomization v;
/* for backward compatibility, read the deprecated wifi.mac-address-randomization setting. */
a = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
"wifi." NM_SETTING_WIRELESS_MAC_ADDRESS_RANDOMIZATION,
self);
v = _nm_utils_ascii_str_to_int64 (a, 10,
NM_SETTING_MAC_RANDOMIZATION_DEFAULT,
NM_SETTING_MAC_RANDOMIZATION_ALWAYS,
NM_SETTING_MAC_RANDOMIZATION_DEFAULT);
if (v == NM_SETTING_MAC_RANDOMIZATION_ALWAYS)
addr = NM_CLONED_MAC_RANDOM;
}
} else if ( NM_CLONED_MAC_IS_SPECIAL (a)
|| nm_utils_hwaddr_valid (a, ETH_ALEN))
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
addr = *out_addr = g_steal_pointer (&a);
}
return addr;
}
all: make MAC address randomization algorithm configurable For the per-connection settings "ethernet.cloned-mac-address" and "wifi.cloned-mac-address", and for the per-device setting "wifi.scan-rand-mac-address", we may generate MAC addresses using either the "random" or "stable" algorithm. Add new properties "generate-mac-address-mask" that allow to configure which bits of the MAC address will be scrambled. By default, the "random" and "stable" algorithms scamble all bits of the MAC address, including the OUI part and generate a locally- administered, unicast address. By specifying a MAC address mask, we can now configure to perserve parts of the current MAC address of the device. For example, setting "FF:FF:FF:00:00:00" will preserve the first 3 octects of the current MAC address. One can also explicitly specify a MAC address to use instead of the current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00" sets the OUI part of the MAC address to "68:F7:28" while scrambling the last 3 octects. Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble all bits of the MAC address, except clearing the second-least significant bit. Thus, creating a burned-in address, globally administered. One can also supply a list of MAC addresses like "FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which case a MAC address is choosen randomly. To fully scamble the MAC address one can configure "02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00". which also randomly creates either a locally or globally administered address. With this, the following macchanger options can be implemented: `macchanger --random` This is the default if no mask is configured. -> "" while is the same as: -> "00:00:00:00:00:00" -> "02:00:00:00:00:00 02:00:00:00:00:00" `macchanger --random --bia` -> "02:00:00:00:00:00 00:00:00:00:00:00" `macchanger --ending` This option cannot be fully implemented, because macchanger uses the current MAC address but also implies --bia. -> "FF:FF:FF:00:00:00" This would yields the same result only if the current MAC address is already a burned-in address too. Otherwise, it has not the same effect as --ending. -> "FF:FF:FF:00:00:00 <MAC_ADDR>" Alternatively, instead of using the current MAC address, spell the OUI part out. But again, that is not really the same as macchanger does because you explictly have to name the OUI part to use. `machanger --another` `machanger --another_any` -> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..." "$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
2016-06-22 20:31:39 +02:00
static const char *
_get_generate_mac_address_mask_setting (NMDevice *self, NMConnection *connection, gboolean is_wifi, char **out_value)
{
NMSetting *setting;
const char *value = NULL;
char *a;
nm_assert (out_value && !*out_value);
setting = nm_connection_get_setting (connection,
is_wifi ? NM_TYPE_SETTING_WIRELESS : NM_TYPE_SETTING_WIRED);
if (setting) {
value = is_wifi
? nm_setting_wireless_get_generate_mac_address_mask ((NMSettingWireless *) setting)
: nm_setting_wired_get_generate_mac_address_mask ((NMSettingWired *) setting);
if (value)
return value;
}
a = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
is_wifi ? "wifi.generate-mac-address-mask" : "ethernet.generate-mac-mac-address-mask",
self);
if (!a)
return NULL;
*out_value = a;
return a;
}
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
gboolean
nm_device_hw_addr_is_explict (NMDevice *self)
{
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
device: change hw_addr_type field to bitfield type We don't want to waste a full "int" size to store the @hw_addr_type in NMDevicePrivate. Previously, that was hacked around by using guint8. Now, instead use a bitfield which has the right type.
2017-02-02 12:34:30 +01:00
return !NM_IN_SET ((HwAddrType) priv->hw_addr_type,
HW_ADDR_TYPE_PERMANENT,
HW_ADDR_TYPE_UNSET);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
}
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
static gboolean
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
_hw_addr_matches (NMDevice *self, const guint8 *addr, gsize addr_len)
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
{
const char *cur_addr;
cur_addr = nm_device_get_hw_address (self);
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
return cur_addr && nm_utils_hwaddr_matches (addr, addr_len, cur_addr, -1);
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
}
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
static gboolean
_hw_addr_set (NMDevice *self,
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
const char *const addr,
const char *const operation,
const char *const detail)
core: add a "default-unmanaged" setting for devices Allow devices to declare themselves unmanaged-by-default, but tweak nm-manager and nm-policy to allow activating matching connections on those devices anyway. (This ensures that NM keeps its hands completely off the device unless the user explicitly asks it to do something with it.)
2013-04-24 10:40:58 -04:00
{
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
NMDevicePrivate *priv;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
gboolean success = FALSE;
core: don't warn when setting address of non-existing link Trying to set a property on a device that does not exist is not something necessarily wrong. Don't print error/warning messages. <trace> [1467707267.2887] device[0x55a74adbdaf0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, unmanage)... <debug> [1467707267.2887] platform: link: setting '(null)' (2) hardware address <debug> [1467707267.2887] platform-linux: link: change 2: address: 68:F7:28:61:68:F7 (6 bytes) <debug> [1467707267.2887] platform-linux: do-request-link: 2 <debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 226 <debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 227 <error> [1467707267.2888] platform-linux: do-change-link[2]: failure changing link: failure 19 (No such device) <warn> [1467707267.2888] device (enp0s25): set-hw-addr: failed to reset MAC address to 68:F7:28:61:68:F7 (unmanage)
2016-07-05 10:41:18 +02:00
NMPlatformError plerr;
libnm-core: change all mac-address properties to G_TYPE_STRING Make all mac-address properties (including NMSettingBluetooth:bdaddr, NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be strings, using _nm_setting_class_transform_property() to handle translating to/from binary form when dealing with D-Bus. Update everything accordingly for the change, and also add a test for transformed setting properties to test-general.
2014-07-30 10:57:45 -04:00
guint8 addr_bytes[NM_UTILS_HWADDR_LEN_MAX];
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
gsize addr_len;
wifi: implement MAC address randomization in NetworkManager instead of supplicant 'wireless.mac-address-randomization' broke 'wireless.cloned-mac-address', because we would always set 'PreassocMacAddr=1'. The reason is that supplicant would set 'wpa_s->mac_addr_changed' during scanning, and later during association it would either set a random MAC address or reset the permanent MAC address [1]. Anyway, 'wireless.mac-address-randomization' conflicts with 'wireless.cloned-mac-address'. Instead of letting supplicant set the MAC address, manage the MAC addresses entirely from NetworkManager. Supplicant should not touch it. [1] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=f885b8e97cf39b56fe7ca6577890f2d20df7ae08#n1663
2016-06-20 12:28:04 +02:00
gboolean was_up;
core: add a "default-unmanaged" setting for devices Allow devices to declare themselves unmanaged-by-default, but tweak nm-manager and nm-policy to allow activating matching connections on those devices anyway. (This ensures that NM keeps its hands completely off the device unless the user explicitly asks it to do something with it.)
2013-04-24 10:40:58 -04:00
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
nm_assert (NM_IS_DEVICE (self));
nm_assert (addr);
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
nm_assert (operation);
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
if (!_nm_utils_hwaddr_aton (addr, addr_bytes, sizeof (addr_bytes), &addr_len))
g_return_val_if_reached (FALSE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Do nothing if current MAC is same */
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
if (_hw_addr_matches (self, addr_bytes, addr_len)) {
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
_LOGT (LOGD_DEVICE, "set-hw-addr: no MAC address change needed (%s)", addr);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
return TRUE;
}
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
if ( priv->hw_addr_len
&& priv->hw_addr_len != addr_len)
g_return_val_if_reached (FALSE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
_LOGT (LOGD_DEVICE, "set-hw-addr: setting MAC address to '%s' (%s, %s)...", addr, operation, detail);
device: cleanup logging for setting MAC address Give all related messages a "set-hw-addr"/"hw-addr" prefix.
2016-05-20 13:36:09 +02:00
wifi: implement MAC address randomization in NetworkManager instead of supplicant 'wireless.mac-address-randomization' broke 'wireless.cloned-mac-address', because we would always set 'PreassocMacAddr=1'. The reason is that supplicant would set 'wpa_s->mac_addr_changed' during scanning, and later during association it would either set a random MAC address or reset the permanent MAC address [1]. Anyway, 'wireless.mac-address-randomization' conflicts with 'wireless.cloned-mac-address'. Instead of letting supplicant set the MAC address, manage the MAC addresses entirely from NetworkManager. Supplicant should not touch it. [1] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=f885b8e97cf39b56fe7ca6577890f2d20df7ae08#n1663
2016-06-20 12:28:04 +02:00
was_up = nm_device_is_up (self);
if (was_up) {
/* Can't change MAC address while device is up */
nm_device_take_down (self, FALSE);
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
plerr = nm_platform_link_set_address (nm_device_get_platform (self), nm_device_get_ip_ifindex (self), addr_bytes, addr_len);
core: don't warn when setting address of non-existing link Trying to set a property on a device that does not exist is not something necessarily wrong. Don't print error/warning messages. <trace> [1467707267.2887] device[0x55a74adbdaf0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, unmanage)... <debug> [1467707267.2887] platform: link: setting '(null)' (2) hardware address <debug> [1467707267.2887] platform-linux: link: change 2: address: 68:F7:28:61:68:F7 (6 bytes) <debug> [1467707267.2887] platform-linux: do-request-link: 2 <debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 226 <debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 227 <error> [1467707267.2888] platform-linux: do-change-link[2]: failure changing link: failure 19 (No such device) <warn> [1467707267.2888] device (enp0s25): set-hw-addr: failed to reset MAC address to 68:F7:28:61:68:F7 (unmanage)
2016-07-05 10:41:18 +02:00
success = (plerr == NM_PLATFORM_ERROR_SUCCESS);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
if (success) {
/* MAC address succesfully changed; update the current MAC to match */
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_update_hw_address (self);
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
if (_hw_addr_matches (self, addr_bytes, addr_len)) {
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
_LOGI (LOGD_DEVICE, "set-hw-addr: %s MAC address to %s (%s)",
operation, addr, detail);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
} else {
device: cleanup _hw_addr_set() No change in behavior, just reorganize. Fixes: 32f7c1d4b9aba597a99128631f07c2985149f303
2016-09-13 11:16:11 +02:00
gint64 poll_end, now;
device: add hack to wait after changing MAC address It seems some drivers return success for nm_platform_link_set_address(), but at that point the address did not yet actually change *sigh*. It changes a bit later, possibly after setting the device up. Add a workaround to retry reading the MAC address when platform indicates success but the address still differs at first. https://bugzilla.gnome.org/show_bug.cgi?id=770456
2016-08-29 18:28:34 +02:00
_LOGD (LOGD_DEVICE,
"set-hw-addr: new MAC address %s not successfully %s (%s) (refresh link)",
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
addr, operation, detail);
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
/* The platform call indicated success, however the address is not
* as expected. That is either due to a driver issue (brcmfmac, bgo#770456,
* rh#1374023) or a race where externally the MAC address was reset.
* The race is rather unlikely.
*
* The alternative would be to postpone the activation in case the
* MAC address is not yet ready and poll without blocking. However,
* that is rather complicated and it is not expected that this case
* happens for regular drivers.
* Note that brcmfmac can block NetworkManager for 500 msec while
* taking down the device. Let's add annother 100 msec to that.
*
* wait/poll up to 100 msec until it changes. */
poll_end = nm_utils_get_monotonic_timestamp_us () + (100 * 1000);
for (;;) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
if (!nm_platform_link_refresh (nm_device_get_platform (self), nm_device_get_ip_ifindex (self)))
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
goto handle_fail;
if (!nm_device_update_hw_address (self))
goto handle_wait;
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
if (!_hw_addr_matches (self, addr_bytes, addr_len))
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
goto handle_fail;
break;
handle_wait:
now = nm_utils_get_monotonic_timestamp_us ();
if (now < poll_end) {
g_usleep (NM_MIN (poll_end - now, 500));
continue;
}
handle_fail:
device: wait for MAC address change to complete before setting interface up Some drivers (brcmfmac) don't change the MAC address right away. NetworkManager works around that by waiting synchronously until the address changes (commit 1a85103765d4eaa0acab6b03658a4f9cfe684a64). wpa_supplicant on the other hand, only re-reads the MAC address when changing state from DISABLED to ENABLED, which happens when the interface comes up. That is a bug in wpa_supplicant and the driver, but we can work-around by waiting until the MAC address actually changed before setting the interface IFF_UP. Also note, that there is still a race in wpa_supplicant which might miss a change to DISABLED state altogether. https://bugzilla.gnome.org/show_bug.cgi?id=770504 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-11 09:48:56 +02:00
success = FALSE;
break;
device: workaround driver issue with delayed change of MAC address brcmfmac and possibly other drivers don't change the MAC address right away, but instead the result is delayed. That is problematic because we cannot continue activation before the MAC address is settled. Add a hack to workaround the issue by waiting until the MAC address changed. The previous attempt to workaround this was less intrusive: we would just refresh the link once and check the result. But that turns out not to be sufficent for all cases. Now, wait and poll. https://bugzilla.gnome.org/show_bug.cgi?id=770456 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-07 23:47:14 +02:00
}
device: cleanup _hw_addr_set() No change in behavior, just reorganize. Fixes: 32f7c1d4b9aba597a99128631f07c2985149f303
2016-09-13 11:16:11 +02:00
if (success) {
_LOGI (LOGD_DEVICE, "set-hw-addr: %s MAC address to %s (%s)",
operation, addr, detail);
} else {
_LOGW (LOGD_DEVICE,
"set-hw-addr: new MAC address %s not successfully %s (%s)",
addr, operation, detail);
}
device: wait for MAC address change to complete before setting interface up Some drivers (brcmfmac) don't change the MAC address right away. NetworkManager works around that by waiting synchronously until the address changes (commit 1a85103765d4eaa0acab6b03658a4f9cfe684a64). wpa_supplicant on the other hand, only re-reads the MAC address when changing state from DISABLED to ENABLED, which happens when the interface comes up. That is a bug in wpa_supplicant and the driver, but we can work-around by waiting until the MAC address actually changed before setting the interface IFF_UP. Also note, that there is still a race in wpa_supplicant which might miss a change to DISABLED state altogether. https://bugzilla.gnome.org/show_bug.cgi?id=770504 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-11 09:48:56 +02:00
}
device: cleanup _hw_addr_set() No change in behavior, just reorganize. Fixes: 32f7c1d4b9aba597a99128631f07c2985149f303
2016-09-13 11:16:11 +02:00
} else {
_NMLOG (plerr == NM_PLATFORM_ERROR_NOT_FOUND ? LOGL_DEBUG : LOGL_WARN,
LOGD_DEVICE, "set-hw-addr: failed to %s MAC address to %s (%s) (%s)",
operation, addr, detail,
platform: pass string buffer to nm_platform_error_to_string() and print numeric errno Change the output of nm_platform_error_to_string() to print the numeric value. Also, accept a string buffer instead of using an alloca() allocated buffer. There is still a macro to provide the previous functionality, but it was ill-suited to call from inside a loop.
2017-08-21 19:18:45 +02:00
nm_platform_error_to_string_a (plerr));
device: wait for MAC address change to complete before setting interface up Some drivers (brcmfmac) don't change the MAC address right away. NetworkManager works around that by waiting synchronously until the address changes (commit 1a85103765d4eaa0acab6b03658a4f9cfe684a64). wpa_supplicant on the other hand, only re-reads the MAC address when changing state from DISABLED to ENABLED, which happens when the interface comes up. That is a bug in wpa_supplicant and the driver, but we can work-around by waiting until the MAC address actually changed before setting the interface IFF_UP. Also note, that there is still a race in wpa_supplicant which might miss a change to DISABLED state altogether. https://bugzilla.gnome.org/show_bug.cgi?id=770504 https://bugzilla.redhat.com/show_bug.cgi?id=1374023
2016-09-11 09:48:56 +02:00
}
if (was_up) {
if (!nm_device_bring_up (self, TRUE, NULL))
return FALSE;
device: add hack to wait after changing MAC address It seems some drivers return success for nm_platform_link_set_address(), but at that point the address did not yet actually change *sigh*. It changes a bit later, possibly after setting the device up. Add a workaround to retry reading the MAC address when platform indicates success but the address still differs at first. https://bugzilla.gnome.org/show_bug.cgi?id=770456
2016-08-29 18:28:34 +02:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
return success;
core: add a "default-unmanaged" setting for devices Allow devices to declare themselves unmanaged-by-default, but tweak nm-manager and nm-policy to allow activating matching connections on those devices anyway. (This ensures that NM keeps its hands completely off the device unless the user explicitly asks it to do something with it.)
2013-04-24 10:40:58 -04:00
}
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
gboolean
device: add @set_permanent argument to nm_device_hw_addr_set() In a later commit the function will be used to restore a MAC address without changing its type.
2016-10-25 16:41:42 +02:00
nm_device_hw_addr_set (NMDevice *self,
const char *addr,
const char *detail,
gboolean set_permanent)
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
{
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
if (!addr)
g_return_val_if_reached (FALSE);
device: add @set_permanent argument to nm_device_hw_addr_set() In a later commit the function will be used to restore a MAC address without changing its type.
2016-10-25 16:41:42 +02:00
if (set_permanent) {
/* The type is set to PERMANENT by NMDeviceVlan when taking the MAC
* address from the parent and by NMDeviceWifi when setting a random MAC
* address during scanning.
*/
priv->hw_addr_type = HW_ADDR_TYPE_PERMANENT;
}
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
return _hw_addr_set (self, addr, "set", detail);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
}
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
/*
* _hw_addr_get_cloned:
* @self: a #NMDevice
* @connection: a #NMConnection
* @is_wifi: whether the device is Wi-Fi
* @preserve: (out): whether the address must be reset to initial one
* @hwaddr: (out): the cloned MAC address to set on interface
* @hwaddr_type: (out): the type of address to set
* @hwaddr_detail: (out): the detail (origin) of address to set
* @error: (out): on return, an error or %NULL
*
* Computes the MAC to be set on a interface. On success, one of the
* following exclusive conditions are verified:
*
* - @preserve is %TRUE: the address must be reset to the initial one
* - @hwaddr is not %NULL: the given address must be set on the device
* - @hwaddr is %NULL and @preserve is %FALSE: no action needed
*
* Returns: %FALSE in case of error in determining the cloned MAC address,
* %TRUE otherwise
*/
static gboolean
_hw_addr_get_cloned (NMDevice *self, NMConnection *connection, gboolean is_wifi,
gboolean *preserve, char **hwaddr, HwAddrType *hwaddr_type,
char **hwaddr_detail, GError **error)
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
{
NMDevicePrivate *priv;
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
gs_free char *addr_setting_free = NULL;
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
gs_free char *hw_addr_generated = NULL;
all: make MAC address randomization algorithm configurable For the per-connection settings "ethernet.cloned-mac-address" and "wifi.cloned-mac-address", and for the per-device setting "wifi.scan-rand-mac-address", we may generate MAC addresses using either the "random" or "stable" algorithm. Add new properties "generate-mac-address-mask" that allow to configure which bits of the MAC address will be scrambled. By default, the "random" and "stable" algorithms scamble all bits of the MAC address, including the OUI part and generate a locally- administered, unicast address. By specifying a MAC address mask, we can now configure to perserve parts of the current MAC address of the device. For example, setting "FF:FF:FF:00:00:00" will preserve the first 3 octects of the current MAC address. One can also explicitly specify a MAC address to use instead of the current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00" sets the OUI part of the MAC address to "68:F7:28" while scrambling the last 3 octects. Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble all bits of the MAC address, except clearing the second-least significant bit. Thus, creating a burned-in address, globally administered. One can also supply a list of MAC addresses like "FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which case a MAC address is choosen randomly. To fully scamble the MAC address one can configure "02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00". which also randomly creates either a locally or globally administered address. With this, the following macchanger options can be implemented: `macchanger --random` This is the default if no mask is configured. -> "" while is the same as: -> "00:00:00:00:00:00" -> "02:00:00:00:00:00 02:00:00:00:00:00" `macchanger --random --bia` -> "02:00:00:00:00:00 00:00:00:00:00:00" `macchanger --ending` This option cannot be fully implemented, because macchanger uses the current MAC address but also implies --bia. -> "FF:FF:FF:00:00:00" This would yields the same result only if the current MAC address is already a burned-in address too. Otherwise, it has not the same effect as --ending. -> "FF:FF:FF:00:00:00 <MAC_ADDR>" Alternatively, instead of using the current MAC address, spell the OUI part out. But again, that is not really the same as macchanger does because you explictly have to name the OUI part to use. `machanger --another` `machanger --another_any` -> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..." "$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
2016-06-22 20:31:39 +02:00
gs_free char *generate_mac_address_mask_tmp = NULL;
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
const char *addr, *addr_setting;
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
char *addr_out;
HwAddrType type_out;
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
g_return_val_if_fail (NM_IS_CONNECTION (connection), FALSE);
g_return_val_if_fail (!error || !*error, FALSE);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
priv = NM_DEVICE_GET_PRIVATE (self);
if (!connection)
g_return_val_if_reached (FALSE);
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
addr = addr_setting = _get_cloned_mac_address_setting (self, connection, is_wifi, &addr_setting_free);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
wifi: implement MAC address randomization in NetworkManager instead of supplicant 'wireless.mac-address-randomization' broke 'wireless.cloned-mac-address', because we would always set 'PreassocMacAddr=1'. The reason is that supplicant would set 'wpa_s->mac_addr_changed' during scanning, and later during association it would either set a random MAC address or reset the permanent MAC address [1]. Anyway, 'wireless.mac-address-randomization' conflicts with 'wireless.cloned-mac-address'. Instead of letting supplicant set the MAC address, manage the MAC addresses entirely from NetworkManager. Supplicant should not touch it. [1] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=f885b8e97cf39b56fe7ca6577890f2d20df7ae08#n1663
2016-06-20 12:28:04 +02:00
if (nm_streq (addr, NM_CLONED_MAC_PRESERVE)) {
/* "preserve" means to reset the initial MAC address. */
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
NM_SET_OUT (preserve, TRUE);
NM_SET_OUT (hwaddr, NULL);
NM_SET_OUT (hwaddr_type, HW_ADDR_TYPE_UNSET);
NM_SET_OUT (hwaddr_detail, g_steal_pointer (&addr_setting_free) ?: g_strdup (addr_setting));
return TRUE;
wifi: implement MAC address randomization in NetworkManager instead of supplicant 'wireless.mac-address-randomization' broke 'wireless.cloned-mac-address', because we would always set 'PreassocMacAddr=1'. The reason is that supplicant would set 'wpa_s->mac_addr_changed' during scanning, and later during association it would either set a random MAC address or reset the permanent MAC address [1]. Anyway, 'wireless.mac-address-randomization' conflicts with 'wireless.cloned-mac-address'. Instead of letting supplicant set the MAC address, manage the MAC addresses entirely from NetworkManager. Supplicant should not touch it. [1] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=f885b8e97cf39b56fe7ca6577890f2d20df7ae08#n1663
2016-06-20 12:28:04 +02:00
}
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
if (nm_streq (addr, NM_CLONED_MAC_PERMANENT)) {
device: don't set a fake permanent hardware address Software devices don't have a permanent hardware address and thus it doesn't make sense to enforce the 'fake' (generated) permanent one when cloned-mac-address=permanent. Also, setting the fake permanent address on bond devices, prevents them from inheriting the first slave hardware address, so let's just skip the setting of MAC when cloned-mac-address=permanent and there is no real permanent address. https://bugzilla.redhat.com/show_bug.cgi?id=1472965
2017-07-25 10:37:14 +02:00
gboolean is_fake;
addr = nm_device_get_permanent_hw_address_full (self, TRUE, &is_fake);
if (is_fake) {
/* Preserve the current address if the permanent address if fake */
NM_SET_OUT (preserve, TRUE);
NM_SET_OUT (hwaddr, NULL);
NM_SET_OUT (hwaddr_type, HW_ADDR_TYPE_UNSET);
NM_SET_OUT (hwaddr_detail, g_steal_pointer (&addr_setting_free) ?: g_strdup (addr_setting));
return TRUE;
} else if (!addr) {
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
g_set_error_literal (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_FAILED,
"failed to retrieve permanent address");
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
return FALSE;
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
}
addr_out = g_strdup (addr);
type_out = HW_ADDR_TYPE_PERMANENT;
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
} else if (NM_IN_STRSET (addr, NM_CLONED_MAC_RANDOM)) {
device: don't regenerate MAC address on multiple _set_cloned() calls Wi-Fi device first have a state-transition "disconnected -> prepare" on which they run activate_stage1_device_prepare() and set the MAC address the first time. Later, after getting secrets, they have a state transition "need-auth -> prepare" and end up calling nm_device_hw_addr_set_cloned() again. In this case, we must not regenerate a new MAC address but bail out. There is a small uncertainty there, because we are not sure that the previously generated connection really entailed the same settings. But since we always call nm_device_hw_addr_reset() during device deactivation, this cannot be a left-over from a previous activation and is thus the same activation request.
2016-06-23 16:01:10 +02:00
if (priv->hw_addr_type == HW_ADDR_TYPE_GENERATED) {
/* hm, we already use a generate MAC address. Most certainly, that is from the same
* activation request, so we should not create a new random address, instead keep
* the current. */
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
goto out_no_action;
device: don't regenerate MAC address on multiple _set_cloned() calls Wi-Fi device first have a state-transition "disconnected -> prepare" on which they run activate_stage1_device_prepare() and set the MAC address the first time. Later, after getting secrets, they have a state transition "need-auth -> prepare" and end up calling nm_device_hw_addr_set_cloned() again. In this case, we must not regenerate a new MAC address but bail out. There is a small uncertainty there, because we are not sure that the previously generated connection really entailed the same settings. But since we always call nm_device_hw_addr_reset() during device deactivation, this cannot be a left-over from a previous activation and is thus the same activation request.
2016-06-23 16:01:10 +02:00
}
all: make MAC address randomization algorithm configurable For the per-connection settings "ethernet.cloned-mac-address" and "wifi.cloned-mac-address", and for the per-device setting "wifi.scan-rand-mac-address", we may generate MAC addresses using either the "random" or "stable" algorithm. Add new properties "generate-mac-address-mask" that allow to configure which bits of the MAC address will be scrambled. By default, the "random" and "stable" algorithms scamble all bits of the MAC address, including the OUI part and generate a locally- administered, unicast address. By specifying a MAC address mask, we can now configure to perserve parts of the current MAC address of the device. For example, setting "FF:FF:FF:00:00:00" will preserve the first 3 octects of the current MAC address. One can also explicitly specify a MAC address to use instead of the current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00" sets the OUI part of the MAC address to "68:F7:28" while scrambling the last 3 octects. Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble all bits of the MAC address, except clearing the second-least significant bit. Thus, creating a burned-in address, globally administered. One can also supply a list of MAC addresses like "FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which case a MAC address is choosen randomly. To fully scamble the MAC address one can configure "02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00". which also randomly creates either a locally or globally administered address. With this, the following macchanger options can be implemented: `macchanger --random` This is the default if no mask is configured. -> "" while is the same as: -> "00:00:00:00:00:00" -> "02:00:00:00:00:00 02:00:00:00:00:00" `macchanger --random --bia` -> "02:00:00:00:00:00 00:00:00:00:00:00" `macchanger --ending` This option cannot be fully implemented, because macchanger uses the current MAC address but also implies --bia. -> "FF:FF:FF:00:00:00" This would yields the same result only if the current MAC address is already a burned-in address too. Otherwise, it has not the same effect as --ending. -> "FF:FF:FF:00:00:00 <MAC_ADDR>" Alternatively, instead of using the current MAC address, spell the OUI part out. But again, that is not really the same as macchanger does because you explictly have to name the OUI part to use. `machanger --another` `machanger --another_any` -> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..." "$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
2016-06-22 20:31:39 +02:00
hw_addr_generated = nm_utils_hw_addr_gen_random_eth (nm_device_get_initial_hw_address (self),
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
_get_generate_mac_address_mask_setting (self, connection,
is_wifi,
&generate_mac_address_mask_tmp));
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
if (!hw_addr_generated) {
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
g_set_error (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_FAILED,
"failed to generate %s MAC address", "random");
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
return FALSE;
}
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
addr_out = g_steal_pointer (&hw_addr_generated);
type_out = HW_ADDR_TYPE_GENERATED;
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
} else if (NM_IN_STRSET (addr, NM_CLONED_MAC_STABLE)) {
NMUtilsStableType stable_type;
const char *stable_id;
device: don't regenerate MAC address on multiple _set_cloned() calls Wi-Fi device first have a state-transition "disconnected -> prepare" on which they run activate_stage1_device_prepare() and set the MAC address the first time. Later, after getting secrets, they have a state transition "need-auth -> prepare" and end up calling nm_device_hw_addr_set_cloned() again. In this case, we must not regenerate a new MAC address but bail out. There is a small uncertainty there, because we are not sure that the previously generated connection really entailed the same settings. But since we always call nm_device_hw_addr_reset() during device deactivation, this cannot be a left-over from a previous activation and is thus the same activation request.
2016-06-23 16:01:10 +02:00
if (priv->hw_addr_type == HW_ADDR_TYPE_GENERATED) {
/* hm, we already use a generate MAC address. Most certainly, that is from the same
* activation request, so let's skip creating the stable address anew. */
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
goto out_no_action;
device: don't regenerate MAC address on multiple _set_cloned() calls Wi-Fi device first have a state-transition "disconnected -> prepare" on which they run activate_stage1_device_prepare() and set the MAC address the first time. Later, after getting secrets, they have a state transition "need-auth -> prepare" and end up calling nm_device_hw_addr_set_cloned() again. In this case, we must not regenerate a new MAC address but bail out. There is a small uncertainty there, because we are not sure that the previously generated connection really entailed the same settings. But since we always call nm_device_hw_addr_reset() during device deactivation, this cannot be a left-over from a previous activation and is thus the same activation request.
2016-06-23 16:01:10 +02:00
}
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
stable_id = _get_stable_id (self, connection, &stable_type);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
if (stable_id) {
hw_addr_generated = nm_utils_hw_addr_gen_stable_eth (stable_type, stable_id,
all: make MAC address randomization algorithm configurable For the per-connection settings "ethernet.cloned-mac-address" and "wifi.cloned-mac-address", and for the per-device setting "wifi.scan-rand-mac-address", we may generate MAC addresses using either the "random" or "stable" algorithm. Add new properties "generate-mac-address-mask" that allow to configure which bits of the MAC address will be scrambled. By default, the "random" and "stable" algorithms scamble all bits of the MAC address, including the OUI part and generate a locally- administered, unicast address. By specifying a MAC address mask, we can now configure to perserve parts of the current MAC address of the device. For example, setting "FF:FF:FF:00:00:00" will preserve the first 3 octects of the current MAC address. One can also explicitly specify a MAC address to use instead of the current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00" sets the OUI part of the MAC address to "68:F7:28" while scrambling the last 3 octects. Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble all bits of the MAC address, except clearing the second-least significant bit. Thus, creating a burned-in address, globally administered. One can also supply a list of MAC addresses like "FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which case a MAC address is choosen randomly. To fully scamble the MAC address one can configure "02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00". which also randomly creates either a locally or globally administered address. With this, the following macchanger options can be implemented: `macchanger --random` This is the default if no mask is configured. -> "" while is the same as: -> "00:00:00:00:00:00" -> "02:00:00:00:00:00 02:00:00:00:00:00" `macchanger --random --bia` -> "02:00:00:00:00:00 00:00:00:00:00:00" `macchanger --ending` This option cannot be fully implemented, because macchanger uses the current MAC address but also implies --bia. -> "FF:FF:FF:00:00:00" This would yields the same result only if the current MAC address is already a burned-in address too. Otherwise, it has not the same effect as --ending. -> "FF:FF:FF:00:00:00 <MAC_ADDR>" Alternatively, instead of using the current MAC address, spell the OUI part out. But again, that is not really the same as macchanger does because you explictly have to name the OUI part to use. `machanger --another` `machanger --another_any` -> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..." "$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
2016-06-22 20:31:39 +02:00
nm_device_get_ip_iface (self),
nm_device_get_initial_hw_address (self),
_get_generate_mac_address_mask_setting (self, connection, is_wifi, &generate_mac_address_mask_tmp));
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
}
if (!hw_addr_generated) {
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
g_set_error (error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_FAILED,
"failed to generate %s MAC address", "stable");
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
return FALSE;
}
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
addr_out = g_steal_pointer (&hw_addr_generated);
type_out = HW_ADDR_TYPE_GENERATED;
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
} else {
/* this must be a valid address. Otherwise, we shouldn't come here. */
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
if (!nm_utils_hwaddr_valid (addr, -1))
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
g_return_val_if_reached (FALSE);
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
addr_out = g_strdup (addr);
type_out = HW_ADDR_TYPE_EXPLICIT;
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
}
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
NM_SET_OUT (preserve, FALSE);
NM_SET_OUT (hwaddr, addr_out);
NM_SET_OUT (hwaddr_type, type_out);
NM_SET_OUT (hwaddr_detail, g_steal_pointer (&addr_setting_free) ?: g_strdup (addr_setting));
return TRUE;
out_no_action:
NM_SET_OUT (preserve, FALSE);
NM_SET_OUT (hwaddr, NULL);
NM_SET_OUT (hwaddr_type, HW_ADDR_TYPE_UNSET);
NM_SET_OUT (hwaddr_detail, NULL);
return TRUE;
}
gboolean
nm_device_hw_addr_get_cloned (NMDevice *self, NMConnection *connection, gboolean is_wifi,
char **hwaddr, gboolean *preserve, GError **error)
{
if (!_hw_addr_get_cloned (self, connection, is_wifi, preserve, hwaddr, NULL, NULL, error))
return FALSE;
return TRUE;
}
gboolean
nm_device_hw_addr_set_cloned (NMDevice *self, NMConnection *connection, gboolean is_wifi)
{
NMDevicePrivate *priv;
gboolean preserve = FALSE;
gs_free char *hwaddr = NULL;
gs_free char *detail = NULL;
HwAddrType type = HW_ADDR_TYPE_UNSET;
gs_free_error GError *error = NULL;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
if (!_hw_addr_get_cloned (self, connection, is_wifi, &preserve, &hwaddr, &type, &detail, &error)) {
_LOGW (LOGD_DEVICE, "set-hw-addr: %s", error->message);
return FALSE;
}
if (preserve)
return nm_device_hw_addr_reset (self, detail);
device: update the address type in nm_device_hw_addr_set_cloned() Commit 029a0a21ea1e ("device: split out cloned MAC decision from nm_device_hw_addr_set_cloned()") accidentally removed the assignment of the new device @hw_addr_type, which then was left to HW_ADDR_TYPE_UNSET. As a consequence, we never restored the initial MAC address when the connection was deactivated. Fix this. Fixes: 029a0a21ea1ebf74a10253845396f06b0194853a
2017-03-30 09:54:20 +02:00
if (hwaddr) {
priv->hw_addr_type = type;
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
return _hw_addr_set (self, hwaddr, "set-cloned", detail);
device: update the address type in nm_device_hw_addr_set_cloned() Commit 029a0a21ea1e ("device: split out cloned MAC decision from nm_device_hw_addr_set_cloned()") accidentally removed the assignment of the new device @hw_addr_type, which then was left to HW_ADDR_TYPE_UNSET. As a consequence, we never restored the initial MAC address when the connection was deactivated. Fix this. Fixes: 029a0a21ea1ebf74a10253845396f06b0194853a
2017-03-30 09:54:20 +02:00
}
device: split out cloned MAC decision from nm_device_hw_addr_set_cloned() In this way, we can query the final cloned address (after special values as 'random', 'stable', etc. have been evaluated) from subclasses.
2017-02-21 15:54:01 +01:00
return TRUE;
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
}
gboolean
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
nm_device_hw_addr_reset (NMDevice *self, const char *detail)
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
{
NMDevicePrivate *priv;
const char *addr;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
if (priv->hw_addr_type == HW_ADDR_TYPE_UNSET)
return TRUE;
priv->hw_addr_type = HW_ADDR_TYPE_UNSET;
device: only set permanent hardware address once While a device is realized, we only want to read the permanent MAC address once. If that fails, we fallback to the current MAC address. Thus, we want the permanent address be stable until the device unrealizes. While we want to fallback to the current MAC address, in some cases the caller wants to know whether this was a "real" permanent MAC address as read via ethtool. For example, when matching an ethernet device against ethernet.mac-address property, the fake (current) address should not be used in such case.
2016-05-20 13:47:23 +02:00
addr = nm_device_get_initial_hw_address (self);
device: extend MAC address handling including randomization for ethernet and wifi Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address" settings. Instead of specifying an explicit MAC address, the additional special values "permanent", "preserve", "random", "random-bia", "stable" and "stable-bia" are supported. "permanent" means to use the permanent hardware address. Previously that was the default if no explict cloned-mac-address was set. The default is thus still "permanent", but it can be overwritten by global configuration. "preserve" means not to configure the MAC address when activating the device. That was actually the default behavior before introducing MAC address handling with commit 1b49f941a69af910b0e68530be7339e8053068e5. "random" and "random-bia" use a randomized MAC address for each connection. "stable" and "stable-bia" use a generated, stable address based on some token. The "bia" suffix says to generate a burned-in address. The stable method by default uses as token the connection UUID, but the token can be explicitly choosen via "stable:<TOKEN>" and "stable-bia:<TOKEN>". On a D-Bus level, the "cloned-mac-address" is a bytestring and thus cannot express the new forms. It is replaced by the new "assigned-mac-address" field. For the GObject property, libnm's API, nmcli, keyfile, etc. the old name "cloned-mac-address" is still used. Deprecating the old field seems more complicated then just extending the use of the existing "cloned-mac-address" field, although the name doesn't match well with the extended meaning. There is some overlap with the "wifi.mac-address-randomization" setting. https://bugzilla.gnome.org/show_bug.cgi?id=705545 https://bugzilla.gnome.org/show_bug.cgi?id=708820 https://bugzilla.gnome.org/show_bug.cgi?id=758301
2016-05-24 15:57:16 +02:00
if (!addr) {
/* as hw_addr_type is not UNSET, we expect that we can get an
* initial address to which to reset. */
g_return_val_if_reached (FALSE);
}
device: log more details when setting MAC address
2016-06-21 11:22:07 +02:00
return _hw_addr_set (self, addr, "reset", detail);
device: refactor setting HW address via nm_device_set_hw_addr() This brings no real change in behavior, except getting rid of the logging domain argument.
2016-05-20 09:41:40 +02:00
}
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
const char *
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
nm_device_get_permanent_hw_address_full (NMDevice *self, gboolean force_freeze, gboolean *out_is_fake)
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
{
NMDevicePrivate *priv;
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
priv = NM_DEVICE_GET_PRIVATE (self);
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
if ( !priv->hw_addr_perm
&& force_freeze) {
/* somebody requests a permanent MAC address, but we don't have it set
* yet. We cannot delay it any longer and try to get it without waiting
* for UDEV. */
nm_device_update_permanent_hw_address (self, TRUE);
}
core: persist the fake permanent hardware address to the device's statefile On devices that have no real permanent hardware address (as returned by ethtool), we take the current MAC address of the device. Currently, NM is a bit flaky about whether to accept such fake permanent addresses for settings like keyfile.unmanaged-devices or the per- connection property ethernet.mac-address. Probably, we should allow using fake addresses there in general. However, that leads to problems because NetworkManager itself changes the current MAC address of such devices. For example when configuing keyfile.unmanaged-device=22:33:44:55:66:77 and later activating a connection with ethernet.cloned-mac-address=22:33:44:55:66:77 we have a strange situation after restart and the device becomes unmanaged. We are going to avoid that, by remembering the fake permanent address in the device state file. This only matters: - for devices that don't have a real permanent address (veth) - if the user or NetworkManager itself changed the MAC address of the device - after a restart of NetworkManager, without reboot. A reboot clears the device state for /var/run/NetworkManager.
2016-10-13 15:56:13 +02:00
NM_SET_OUT (out_is_fake, priv->hw_addr_perm && priv->hw_addr_perm_fake);
return priv->hw_addr_perm;
}
core: move permanent and initial MAC address reading to NMDevice and NMPlatform Ethernet, WiFi, and VLAN used the same implementation for initial address. Ethernet and WiFi used the same implementation (and duplicated code) for permanent MAC address, plus they both used ethtool in what should be generic code, which is better done in the platform.
2014-10-03 17:37:26 -05:00
const char *
device: treat fake permanent MAC address mostly like a real one Now that we persist the fake permanent address across restart of NetworkManager, we want to consider fake addresses as good enough in most cases.
2016-10-13 18:52:12 +02:00
nm_device_get_permanent_hw_address (NMDevice *self)
core: move permanent and initial MAC address reading to NMDevice and NMPlatform Ethernet, WiFi, and VLAN used the same implementation for initial address. Ethernet and WiFi used the same implementation (and duplicated code) for permanent MAC address, plus they both used ethtool in what should be generic code, which is better done in the platform.
2014-10-03 17:37:26 -05:00
{
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
return nm_device_get_permanent_hw_address_full (self, TRUE, NULL);
core: move permanent and initial MAC address reading to NMDevice and NMPlatform Ethernet, WiFi, and VLAN used the same implementation for initial address. Ethernet and WiFi used the same implementation (and duplicated code) for permanent MAC address, plus they both used ethtool in what should be generic code, which is better done in the platform.
2014-10-03 17:37:26 -05:00
}
const char *
nm_device_get_initial_hw_address (NMDevice *self)
{
g_return_val_if_fail (NM_IS_DEVICE (self), NULL);
device/trivial: rename hw-addr related fields in NMDevicePrivate Next I will add two more fields. Being able to efficiently grep the code is important. I want to be able to grep for "->hw_addr" or "\<hw_addr" to find related stuff. Unfortunately, prefixes often result in backward English names, e.g. hw_addr_set/hw_addr_get. I still prefer that over get_hw_addr/set_hw_addr though.
2016-06-03 13:37:08 +02:00
return NM_DEVICE_GET_PRIVATE (self)->hw_addr_initial;
core: move permanent and initial MAC address reading to NMDevice and NMPlatform Ethernet, WiFi, and VLAN used the same implementation for initial address. Ethernet and WiFi used the same implementation (and duplicated code) for permanent MAC address, plus they both used ethtool in what should be generic code, which is better done in the platform.
2014-10-03 17:37:26 -05:00
}
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
/**
* nm_device_spec_match_list:
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* @self: an #NMDevice
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
* @specs: (element-type utf8): a list of device specs
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* Checks if @self matches any of the specifications in @specs. The
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
* currently-supported spec types are:
*
* "mac:00:11:22:33:44:55" - matches a device with the given
* hardware address
*
* "interface-name:foo0" - matches a device with the given
* interface name
*
* "s390-subchannels:00.11.22" - matches a device with the given
* z/VM / s390 subchannels.
*
config: add NMConfigDevice Add NMConfigDevice, which is mostly just a wrapper around nm_device_get_hw_address() and nm_device_spec_match_list(), and implement it in NMDevice. This will be used for config options that match devices. (We can't use NMDevice directly for dependency reasons.)
2013-03-20 09:48:24 -04:00
* "*" - matches any device
*
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
* Returns: #TRUE if @self matches one of the specs in @specs
core: document some NMDevice methods
2013-03-13 13:52:55 -04:00
*/
core: move nm_device_interface_spec_match_list() to nm-device.c
2011-11-17 23:16:50 -06:00
gboolean
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
nm_device_spec_match_list (NMDevice *self, const GSList *specs)
core: add nm_device_spec_match_list_full() This gives a third return value: whether the device did not match.
2017-06-01 22:32:12 +02:00
{
return nm_device_spec_match_list_full (self, specs, FALSE);
}
int
nm_device_spec_match_list_full (NMDevice *self, const GSList *specs, int no_match_value)
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
{
core: refactor evaluation of device's match-spec Previously, we would have different functions like - nm_match_spec_device_type() - nm_match_spec_hwaddr() - nm_match_spec_s390_subchannels() - nm_match_spec_interface_name() which all would handle one type of match-spec. So, to get the overall result whether the arguments match or not, nm_device_spec_match_list() had to stich them together and iterate the list multiple times. Refactor the code to have one nm_match_spec_device() function that gets all relevant paramters. The upside is: - the logic how to evaluate the match-spec is all at one place (match_device_eval()) instead of spread over multiple functions. - It requires iterating the list at most twice. Twice, because we do a fast pre-search for "*". One downside could be, that we have to pass all 4 arguments for the evaluation, even if the might no be needed. That is, because "nm-core-utils.c" shall be independend from NMDevice, it cannot receive a device instance to get the parameters as needed. As we would add new match-types, the argument list would grow. However, all arguments are cached and fetching them from the device's private data is very cheap. (cherry picked from commit b957403efd53ff7d826ac7a4f80487032c03824b)
2017-01-20 19:50:25 +01:00
NMDeviceClass *klass;
NMMatchSpecMatchType m;
everything: use libgudev instead of HAL; merge NM and nm-system-settings The only thing that doesn't work yet is the system-settings service's "auto eth" connections for ethernet devices that don't have an existing connection. Might also have issues with unmanaged devices that can't provide a MAC address until they are brought up, but we'll see.
2009-06-11 00:39:12 -04:00
core: refactor evaluation of device's match-spec Previously, we would have different functions like - nm_match_spec_device_type() - nm_match_spec_hwaddr() - nm_match_spec_s390_subchannels() - nm_match_spec_interface_name() which all would handle one type of match-spec. So, to get the overall result whether the arguments match or not, nm_device_spec_match_list() had to stich them together and iterate the list multiple times. Refactor the code to have one nm_match_spec_device() function that gets all relevant paramters. The upside is: - the logic how to evaluate the match-spec is all at one place (match_device_eval()) instead of spread over multiple functions. - It requires iterating the list at most twice. Twice, because we do a fast pre-search for "*". One downside could be, that we have to pass all 4 arguments for the evaluation, even if the might no be needed. That is, because "nm-core-utils.c" shall be independend from NMDevice, it cannot receive a device instance to get the parameters as needed. As we would add new match-types, the argument list would grow. However, all arguments are cached and fetching them from the device's private data is very cheap. (cherry picked from commit b957403efd53ff7d826ac7a4f80487032c03824b)
2017-01-20 19:50:25 +01:00
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
core: simplify nm_device_spec_match_list() Since NMDevice has a generic get_hw_address() method now, it can do nm_device_spec_match_list() itself (for everything except ethernet, which needs to match against s390 subchannels too). https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-02-12 17:59:37 -05:00
core: refactor evaluation of device's match-spec Previously, we would have different functions like - nm_match_spec_device_type() - nm_match_spec_hwaddr() - nm_match_spec_s390_subchannels() - nm_match_spec_interface_name() which all would handle one type of match-spec. So, to get the overall result whether the arguments match or not, nm_device_spec_match_list() had to stich them together and iterate the list multiple times. Refactor the code to have one nm_match_spec_device() function that gets all relevant paramters. The upside is: - the logic how to evaluate the match-spec is all at one place (match_device_eval()) instead of spread over multiple functions. - It requires iterating the list at most twice. Twice, because we do a fast pre-search for "*". One downside could be, that we have to pass all 4 arguments for the evaluation, even if the might no be needed. That is, because "nm-core-utils.c" shall be independend from NMDevice, it cannot receive a device instance to get the parameters as needed. As we would add new match-types, the argument list would grow. However, all arguments are cached and fetching them from the device's private data is very cheap. (cherry picked from commit b957403efd53ff7d826ac7a4f80487032c03824b)
2017-01-20 19:50:25 +01:00
klass = NM_DEVICE_GET_CLASS (self);
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
core: refactor evaluation of device's match-spec Previously, we would have different functions like - nm_match_spec_device_type() - nm_match_spec_hwaddr() - nm_match_spec_s390_subchannels() - nm_match_spec_interface_name() which all would handle one type of match-spec. So, to get the overall result whether the arguments match or not, nm_device_spec_match_list() had to stich them together and iterate the list multiple times. Refactor the code to have one nm_match_spec_device() function that gets all relevant paramters. The upside is: - the logic how to evaluate the match-spec is all at one place (match_device_eval()) instead of spread over multiple functions. - It requires iterating the list at most twice. Twice, because we do a fast pre-search for "*". One downside could be, that we have to pass all 4 arguments for the evaluation, even if the might no be needed. That is, because "nm-core-utils.c" shall be independend from NMDevice, it cannot receive a device instance to get the parameters as needed. As we would add new match-types, the argument list would grow. However, all arguments are cached and fetching them from the device's private data is very cheap. (cherry picked from commit b957403efd53ff7d826ac7a4f80487032c03824b)
2017-01-20 19:50:25 +01:00
m = nm_match_spec_device (specs,
nm_device_get_iface (self),
nm_device_get_type_description (self),
device: add spec "driver:" to match devices Changing the MAC address of devices is known to fail with certain drivers. Add a device-spec to allow disabling it for for such devices. Related: https://bugzilla.gnome.org/show_bug.cgi?id=777523
2017-03-17 16:18:48 +01:00
nm_device_get_driver (self),
nm_device_get_driver_version (self),
core: refactor evaluation of device's match-spec Previously, we would have different functions like - nm_match_spec_device_type() - nm_match_spec_hwaddr() - nm_match_spec_s390_subchannels() - nm_match_spec_interface_name() which all would handle one type of match-spec. So, to get the overall result whether the arguments match or not, nm_device_spec_match_list() had to stich them together and iterate the list multiple times. Refactor the code to have one nm_match_spec_device() function that gets all relevant paramters. The upside is: - the logic how to evaluate the match-spec is all at one place (match_device_eval()) instead of spread over multiple functions. - It requires iterating the list at most twice. Twice, because we do a fast pre-search for "*". One downside could be, that we have to pass all 4 arguments for the evaluation, even if the might no be needed. That is, because "nm-core-utils.c" shall be independend from NMDevice, it cannot receive a device instance to get the parameters as needed. As we would add new match-types, the argument list would grow. However, all arguments are cached and fetching them from the device's private data is very cheap. (cherry picked from commit b957403efd53ff7d826ac7a4f80487032c03824b)
2017-01-20 19:50:25 +01:00
nm_device_get_permanent_hw_address (self),
klass->get_s390_subchannels ? klass->get_s390_subchannels (self) : NULL);
core: add nm_device_spec_match_list_full() This gives a third return value: whether the device did not match.
2017-06-01 22:32:12 +02:00
switch (m) {
case NM_MATCH_SPEC_MATCH:
return TRUE;
case NM_MATCH_SPEC_NEG_MATCH:
return FALSE;
case NM_MATCH_SPEC_NO_MATCH:
return no_match_value;
}
nm_assert_not_reached ();
return no_match_value;
core: simplify nm_device_spec_match_list() Since NMDevice has a generic get_hw_address() method now, it can do nm_device_spec_match_list() itself (for everything except ethernet, which needs to match against s390 subchannels too). https://bugzilla.gnome.org/show_bug.cgi?id=693684
2013-02-12 17:59:37 -05:00
}
device: add support for 802-1x.auth-timeout Use the per-connection authentication timeout for 802.1X Ethernet, MACsec and Wi-Fi connections. In case the value is not defined, fall back to the global one.
2017-01-19 17:25:29 +01:00
guint
nm_device_get_supplicant_timeout (NMDevice *self)
{
NMConnection *connection;
NMSetting8021x *s_8021x;
gs_free char *value = NULL;
gint timeout;
#define SUPPLICANT_DEFAULT_TIMEOUT 25
g_return_val_if_fail (NM_IS_DEVICE (self), SUPPLICANT_DEFAULT_TIMEOUT);
connection = nm_device_get_applied_connection (self);
g_return_val_if_fail (connection, SUPPLICANT_DEFAULT_TIMEOUT);
s_8021x = nm_connection_get_setting_802_1x (connection);
device: avoid assertion in nm_device_get_supplicant_timeout() for Wi-Fi connection ... without 802-1x setting. NetworkManager[27913]: <trace> [1487689965.7156] device[0x555555bc0060] (wlp3s0): powersave is set to 3 NetworkManager[27913]: <info> [1487689965.7156] Config: added 'ssid' value 'xxx' NetworkManager[27913]: <info> [1487689965.7156] Config: added 'scan_ssid' value '1' NetworkManager[27913]: <info> [1487689965.7156] Config: added 'bssid' value 'xxx' NetworkManager[27913]: <info> [1487689965.7157] Config: added 'key_mgmt' value 'WPA-PSK' NetworkManager[27913]: <info> [1487689965.7157] Config: added 'psk' value '<hidden>' NetworkManager[27913]: <debug> [1487689965.7157] sup-iface[0x555555be0010,wlp3s0]: assoc[0x555555ebd800]: starting association... NetworkManager[27913]: nm_device_get_supplicant_timeout: assertion 's_8021x' failed (gdb) bt ... #3 0x00007ffff4c70419 in g_return_if_fail_warning (log_domain=log_domain@entry=0x55555577610e "NetworkManager", pretty_function=pretty_function@entry=0x5555557725e0 <__func__.44436> "nm_device_get_supplicant_timeout", expression=expression@entry=0x5555557725bb "s_8021x") at gmessages.c:2536 #4 0x000055555568af3a in nm_device_get_supplicant_timeout (self=0x555555bc0060 [NMDeviceWifi]) at src/devices/nm-device.c:12963 #5 0x00007fffe88d7f1e in act_stage2_config (device=<optimized out>, reason=0x7fffffffe000) at src/devices/wifi/nm-device-wifi.c:2651 #6 0x00005555556879f1 in activate_stage2_device_config (self=0x555555bc0060 [NMDeviceWifi]) at src/devices/nm-device.c:4320 #7 0x000055555566876b in activation_source_handle_cb (self=self@entry=0x555555bc0060 [NMDeviceWifi], family=family@entry=2) at src/devices/nm-device.c:4060 #8 0x000055555566882e in activation_source_handle_cb4 (user_data=user_data@entry=0x555555bc0060) at src/devices/nm-device.c:3997 #9 0x00007ffff4c658e7 in g_idle_dispatch (source=0x555555e228c0, callback=0x555555668820 <activation_source_handle_cb4>, user_data=0x555555bc0060) at gmain.c:5545 #10 0x00007ffff4c68e52 in g_main_dispatch (context=0x555555a214d0) at gmain.c:3203 #11 0x00007ffff4c68e52 in g_main_context_dispatch (context=context@entry=0x555555a214d0) at gmain.c:3856 #12 0x00007ffff4c691d0 in g_main_context_iterate (context=0x555555a214d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3929 #13 0x00007ffff4c694f2 in g_main_loop_run (loop=0x555555a1a750) at gmain.c:4125 #14 0x00005555555821fe in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:423 Fixes: 07570e245ac97054027acd928ed09ae2b83e62b0
2017-02-21 16:12:58 +01:00
if (s_8021x) {
timeout = nm_setting_802_1x_get_auth_timeout (s_8021x);
if (timeout > 0)
return timeout;
}
device: add support for 802-1x.auth-timeout Use the per-connection authentication timeout for 802.1X Ethernet, MACsec and Wi-Fi connections. In case the value is not defined, fall back to the global one.
2017-01-19 17:25:29 +01:00
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
"802-1x.auth-timeout",
self);
return _nm_utils_ascii_str_to_int64 (value, 10, 1, G_MAXINT32,
SUPPLICANT_DEFAULT_TIMEOUT);
}
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
gboolean
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
nm_device_auth_retries_try_next (NMDevice *self)
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
{
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
NMDevicePrivate *priv;
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
2017-11-02 09:25:40 +01:00
NMSettingConnection *s_con;
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
int auth_retries;
g_return_val_if_fail (NM_IS_DEVICE (self), FALSE);
priv = NM_DEVICE_GET_PRIVATE (self);
auth_retries = priv->auth_retries;
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
2017-11-02 09:25:40 +01:00
if (G_UNLIKELY (auth_retries == NM_DEVICE_AUTH_RETRIES_UNSET)) {
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
auth_retries = -1;
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
2017-11-02 09:25:40 +01:00
s_con = NM_SETTING_CONNECTION (nm_device_get_applied_setting (self, NM_TYPE_SETTING_CONNECTION));
if (s_con)
auth_retries = nm_setting_connection_get_auth_retries (s_con);
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
if (auth_retries == -1) {
gs_free char *value = NULL;
value = nm_config_data_get_connection_default (NM_CONFIG_GET_DATA,
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
2017-11-02 09:25:40 +01:00
"connection.auth-retries",
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
self);
auth_retries = _nm_utils_ascii_str_to_int64 (value, 10, -1, G_MAXINT32, -1);
}
if (auth_retries == 0)
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
2017-11-02 09:25:40 +01:00
auth_retries = NM_DEVICE_AUTH_RETRIES_INFINITY;
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
else if (auth_retries == -1)
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
2017-11-02 09:25:40 +01:00
auth_retries = NM_DEVICE_AUTH_RETRIES_DEFAULT;
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
else
nm_assert (auth_retries > 0);
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
priv->auth_retries = auth_retries;
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
}
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
2017-11-02 09:25:40 +01:00
if (auth_retries == NM_DEVICE_AUTH_RETRIES_INFINITY)
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
return TRUE;
if (auth_retries <= 0) {
nm_assert (auth_retries == 0);
return FALSE;
}
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
priv->auth_retries--;
device: handle authentication retries using 802-1x.auth-retries setting Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
2017-10-24 11:11:18 +02:00
return TRUE;
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
static const char *
_activation_func_to_string (ActivationHandleFunc func)
{
#define FUNC_TO_STRING_CHECK_AND_RETURN(func, f) \
G_STMT_START { \
if ((func) == (f)) \
return #f; \
} G_STMT_END
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
FUNC_TO_STRING_CHECK_AND_RETURN (func, activate_stage1_device_prepare);
FUNC_TO_STRING_CHECK_AND_RETURN (func, activate_stage2_device_config);
FUNC_TO_STRING_CHECK_AND_RETURN (func, activate_stage3_ip_config_start);
FUNC_TO_STRING_CHECK_AND_RETURN (func, activate_stage4_ip4_config_timeout);
FUNC_TO_STRING_CHECK_AND_RETURN (func, activate_stage4_ip6_config_timeout);
device: rename activate_stage5_ip4_config_commit() to activate_stage5_ip4_config_result() We have nm_device_activate_schedule_ip4_config_result(). The name should match. Note, this affects logging, as we log the function name.
2017-06-01 21:50:40 +02:00
FUNC_TO_STRING_CHECK_AND_RETURN (func, activate_stage5_ip4_config_result);
device: rename nm_device_activate_*() functions The function name is logged, so change them to be more suitable: - drop the "nm_device_" prefix. It is redundant in the logging, and usually our static functions don't have an nm-prefix. - have all functions now start with "activate_stagex_". The stage number corresponds to what we are currently logging during activation: "Activation: Stage 1 of 5 (Device Prepare)..." No other functions start with a "activate_stagex_" prefix, so it's easy to grep.
2015-10-07 12:07:51 +02:00
FUNC_TO_STRING_CHECK_AND_RETURN (func, activate_stage5_ip6_config_commit);
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
g_return_val_if_reached ("unknown");
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
device: refactor scheduling the activation source Every activation-source handler first cleared the current activation-source (activation_source_clear()) and later returned FALSE/G_SOURCE_REMOVE. Do not directly attach the handlers to g_idle_add(). Instead wrap the actual handler. This wrapper - always clears the activation source first - always returns G_SOURCE_REMOVE - does trace logging about invoking the handler This also avoids a possibility for a bug where the handler returns G_SOURCE_REMOVE, without also clearing activation_source_clear().
2015-10-06 11:05:14 +02:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
nm_device_init (NMDevice *self)
{
device: cache pointer to private-data in NMDevice structure We often lookup the private data and retrieve it via NM_DEVICE_GET_PRIVATE(), which in turn calls G_TYPE_INSTANCE_GET_PRIVATE(). Instead cache the pointer to the private data. There are up- and downsides: - requries additional sizeof(gpointer) bytes for each NMDevice. + retrieving the private pointer will be slightly faster. + easier debugging in gdb as it is currently often a pain to retrieve the private data. But most importantly, the allows to change our common pattern to first cache the private data in a variable @priv. That is often cumbersome to write, especially for short functions. This change gives us a choice to use self->priv directly. Such a change should not be aimed for every class. Instead it makes mostly sense for NMDevice, where it pays off better due to the class' size and ubiquitous use. https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00017.html
2015-12-07 17:05:12 +01:00
NMDevicePrivate *priv;
priv = G_TYPE_INSTANCE_GET_PRIVATE (self, NM_TYPE_DEVICE, NMDevicePrivate);
core: use _NM_GET_PRIVATE() macros
2016-09-05 16:55:07 +02:00
self->_priv = priv;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
c_list_init (&priv->slaves);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
priv->netns = g_object_ref (NM_NETNS_GET);
device: improve tracking autoconnect-blocked flags of NMDevice - split NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN in two parts: "wrong-pin" and "manual-disconnect". Setting/unsetting them should be tracked differently, as their reason differs. - no longer initialize/clear the autoconnect-blocked reasons during realize/unrealize of the device. Instead, initialize it once when the object gets created (nm_device_init()), and keep the settings beyond unrealize/realize cycles. This only matters for software devices, as regular devices get deleted after unrealizing once. But for software devices it is essential, because we don't want to forget the autoconnect settings of the device instance. - drop verbose logging about blocking autoconnect due to failed pin. We already log changes to autoconnect-blocked flags with TRACE level. An additional message about this particular issue seems not necessary at INFO level. - in NMManager's do_sleep_wake(), no longer block autoconnect for devices during sleep. We already unmanage the device, which is a far more effective measure to prevent activation. We should not also block autoconnect.
2017-11-07 12:36:17 +01:00
priv->autoconnect_blocked_flags = DEFAULT_AUTOCONNECT
? NM_DEVICE_AUTOCONNECT_BLOCKED_NONE
: NM_DEVICE_AUTOCONNECT_BLOCKED_USER;
device: move tracking auth_retry to NMDevice It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
2017-11-02 10:56:30 +01:00
priv->auth_retries = NM_DEVICE_AUTH_RETRIES_UNSET;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv->type = NM_DEVICE_TYPE_UNKNOWN;
priv->capabilities = NM_DEVICE_CAP_NM_SUPPORTED;
priv->state = NM_DEVICE_STATE_UNMANAGED;
priv->state_reason = NM_DEVICE_STATE_REASON_NONE;
priv->rfkill_type = RFKILL_TYPE_UNKNOWN;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
priv->unmanaged_flags = NM_UNMANAGED_PLATFORM_INIT;
priv->unmanaged_mask = priv->unmanaged_flags;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv->available_connections = g_hash_table_new_full (g_direct_hash, g_direct_equal, g_object_unref, NULL);
core,clients: use our own string hashing function nm_str_hash() Replace the usage of g_str_hash() with our own nm_str_hash(). GLib's g_str_hash() uses djb2 hashing function, just like we do at the moment. The only difference is, that we use a diffrent seed value. Note, that we initialize the hash seed with random data (by calling getrandom() or reading /dev/urandom). That is a change compared to before. This change of the hashing function and accessing the random pool might be undesired for libnm/libnm-core. Hence, the change is not done there as it possibly changes behavior for public API. Maybe we should do that later though. At this point, there isn't much of a change. This patch becomes interesting, if we decide to use a different hashing algorithm.
2017-10-13 16:12:35 +02:00
priv->ip6_saved_properties = g_hash_table_new_full (nm_str_hash, g_str_equal, NULL, g_free);
device: track system interface state in NMDevice When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
2017-03-13 15:34:14 +01:00
priv->sys_iface_state = NM_DEVICE_SYS_IFACE_STATE_EXTERNAL;
policy: fix handling managed devices without default route Before, we would only track a device in NMDefaultRouteManager if it had a default route. Otherwise the entry for the device was removed. That was wrong, because having no entry meant that the interface is assumed and hence we would not touch the interface. Instead we must esplicitly track devices without default route to know when an interface has no default route. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-11-18 16:29:05 +01:00
device/trivial: rename private field in NMDevicePrivate Rename "default_route.v4_configure_first_time" to "v4_commit_first_time". For one, the name "commit" matches better to the @commit variable in ip4_config_merge_and_apply() and ip6_config_merge_and_apply(). Then, we don't need this information only for default-routes, so move the variable out of the @default_route struct.
2015-07-22 11:40:35 +02:00
priv->v4_commit_first_time = TRUE;
priv->v6_commit_first_time = TRUE;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
device: move initialization of ifindex to constructor() Device subclasses (for example NMDeviceWifi) can use the ifindex in their constructor(), but the value now is set later in parent class constructed(). This causes the following: nm_platform_wifi_get_capabilities: assertion 'ifindex > 0' failed Fix this by initializing ifindex earlier in NMDevice's constructor(). While at it, remove the nm_assert (pllink->type != NM_LINK_TYPE_NONE); assertion, since pllink can be NULL there. Fixes: 6db04dc20664479fc71f102a536dbf2f4501c5a2
2015-12-09 10:29:15 +01:00
static GObject*
constructor (GType type,
guint n_construct_params,
GObjectConstructParam *construct_params)
{
GObject *object;
GObjectClass *klass;
NMDevice *self;
NMDevicePrivate *priv;
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
const NMPlatformLink *pllink;
device: move initialization of ifindex to constructor() Device subclasses (for example NMDeviceWifi) can use the ifindex in their constructor(), but the value now is set later in parent class constructed(). This causes the following: nm_platform_wifi_get_capabilities: assertion 'ifindex > 0' failed Fix this by initializing ifindex earlier in NMDevice's constructor(). While at it, remove the nm_assert (pllink->type != NM_LINK_TYPE_NONE); assertion, since pllink can be NULL there. Fixes: 6db04dc20664479fc71f102a536dbf2f4501c5a2
2015-12-09 10:29:15 +01:00
klass = G_OBJECT_CLASS (nm_device_parent_class);
object = klass->constructor (type, n_construct_params, construct_params);
if (!object)
return NULL;
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
device: move initialization of ifindex to constructor() Device subclasses (for example NMDeviceWifi) can use the ifindex in their constructor(), but the value now is set later in parent class constructed(). This causes the following: nm_platform_wifi_get_capabilities: assertion 'ifindex > 0' failed Fix this by initializing ifindex earlier in NMDevice's constructor(). While at it, remove the nm_assert (pllink->type != NM_LINK_TYPE_NONE); assertion, since pllink can be NULL there. Fixes: 6db04dc20664479fc71f102a536dbf2f4501c5a2
2015-12-09 10:29:15 +01:00
self = NM_DEVICE (object);
priv = NM_DEVICE_GET_PRIVATE (self);
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
if ( priv->iface
&& G_LIKELY (!nm_utils_get_testing ())) {
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
pllink = nm_platform_link_get_by_ifname (nm_device_get_platform (self), priv->iface);
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
if (pllink && link_type_compatible (self, pllink->type, NULL, NULL)) {
priv->ifindex = pllink->ifindex;
platform/trivial: rename NMPlatformLink's "flags" field to "n_ifi_flags" There are far too many "flags". Rename the "flags" to "n_ifi_flags" which reminds to "ifi_flags" in 'struct ifinfomsg', but with a distinctive "n_" prefix.
2016-02-29 15:52:27 +01:00
priv->up = NM_FLAGS_HAS (pllink->n_ifi_flags, IFF_UP);
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
}
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
if (priv->hw_addr_perm) {
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
guint8 buf[NM_UTILS_HWADDR_LEN_MAX];
gsize l;
if (!_nm_utils_hwaddr_aton (priv->hw_addr_perm, buf, sizeof (buf), &l)) {
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
g_clear_pointer (&priv->hw_addr_perm, g_free);
g_return_val_if_reached (object);
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
}
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
device: don't allow mutating the device's hardware address length We repeatedly call nm_device_update_hw_address() to reset the cached MAC address of the device. However, we don't allow changing the address length once it is set. Multiple entities (initial, current and permanent MAC address) are all checked to have the same address length. Changing the length would be a very strange thing (and probably indicate a bug somewhere else). Just don't allow that.
2016-10-26 12:20:12 +02:00
priv->hw_addr_len_ = l;
libnm-core/utils: update hwaddr utilities _nm_utils_hwaddr_length() did a validation of the string and returned the length of the address. In all cases where we were interested in that, we also either want to validate the address, get the address in binary form, or canonicalize the address. We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton() which both does the parsing and returning the length.
2016-10-13 17:51:07 +02:00
priv->hw_addr = nm_utils_hwaddr_ntoa (buf, l);
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
_LOGT (LOGD_DEVICE, "hw-addr: has permanent hw-address '%s'", priv->hw_addr_perm);
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
}
device: move initialization of ifindex to constructor() Device subclasses (for example NMDeviceWifi) can use the ifindex in their constructor(), but the value now is set later in parent class constructed(). This causes the following: nm_platform_wifi_get_capabilities: assertion 'ifindex > 0' failed Fix this by initializing ifindex earlier in NMDevice's constructor(). While at it, remove the nm_assert (pllink->type != NM_LINK_TYPE_NONE); assertion, since pllink can be NULL there. Fixes: 6db04dc20664479fc71f102a536dbf2f4501c5a2
2015-12-09 10:29:15 +01:00
return object;
}
static void
constructed (GObject *object)
{
NMDevice *self = NM_DEVICE (object);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMPlatform *platform;
core: earlier software capability detection We need to know whether we can create interfaces of any given NMDevice subclass or not. So don't rely on just the NMPlatformLink for that information, because we won't have a platform link for software devices before we create them.
2014-09-24 17:46:15 -05:00
if (NM_DEVICE_GET_CLASS (self)->get_generic_capabilities)
priv->capabilities |= NM_DEVICE_GET_CLASS (self)->get_generic_capabilities (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
/* Watch for external IP config changes */
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
platform = nm_device_get_platform (self);
device: merge device_ipx_changed() signal handler
2015-06-24 15:54:44 +02:00
g_signal_connect (platform, NM_PLATFORM_SIGNAL_IP4_ADDRESS_CHANGED, G_CALLBACK (device_ipx_changed), self);
g_signal_connect (platform, NM_PLATFORM_SIGNAL_IP6_ADDRESS_CHANGED, G_CALLBACK (device_ipx_changed), self);
g_signal_connect (platform, NM_PLATFORM_SIGNAL_IP4_ROUTE_CHANGED, G_CALLBACK (device_ipx_changed), self);
g_signal_connect (platform, NM_PLATFORM_SIGNAL_IP6_ROUTE_CHANGED, G_CALLBACK (device_ipx_changed), self);
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
g_signal_connect (platform, NM_PLATFORM_SIGNAL_LINK_CHANGED, G_CALLBACK (link_changed_cb), self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
priv->settings = g_object_ref (NM_SETTINGS_GET);
g_assert (priv->settings);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
g_signal_connect (priv->settings,
NM_SETTINGS_SIGNAL_CONNECTION_ADDED,
G_CALLBACK (cp_connection_added),
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
self);
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
g_signal_connect (priv->settings,
NM_SETTINGS_SIGNAL_CONNECTION_UPDATED,
G_CALLBACK (cp_connection_updated),
self);
g_signal_connect (priv->settings,
NM_SETTINGS_SIGNAL_CONNECTION_REMOVED,
G_CALLBACK (cp_connection_removed),
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
G_OBJECT_CLASS (nm_device_parent_class)->constructed (object);
device: log message when constructing NMDevice instance
2015-08-11 13:35:02 +02:00
_LOGD (LOGD_DEVICE, "constructed (%s)", G_OBJECT_TYPE_NAME (self));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
}
static void
dispose (GObject *object)
{
NMDevice *self = NM_DEVICE (object);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
NMPlatform *platform;
device: log message when constructing NMDevice instance
2015-08-11 13:35:02 +02:00
_LOGD (LOGD_DEVICE, "disposing");
trivial: add some debug messages on device destruction/removal
2014-12-18 10:23:06 -06:00
device: clear deactivating_cancellable in dispose() It is most likely not needed. Add it just to be sure.
2017-03-13 12:02:09 +01:00
nm_clear_g_cancellable (&priv->deactivating_cancellable);
manager: fix preserving assume state during activation Originally 850c977 "device: track system interface state in NMDevice", intended that a connection can only be assumed initially when seeing a device for the first time. Assuming a connection later was to be prevented by setting device's sys-iface-state to MANAGED. That changed too much in behavior, because we used to assume external connections also when they are activated later on. So this was attempted to get fixed by - acf1067 nm-manager: try assuming connections on managed devices - b6b7d90 manager: avoid generating in memory connections during startup for managed devices It's probably just wrong to prevent assuming connections based on the sys-iface-state. So drop the check for sys-iface-state from recheck_assume_connection(). Now, we can assume anytime on managed, disconnected interfaces, like previously. Btw, note that priv->startup is totally wrong to check there, because priv->startup has the sole purpose of tracking startup-complete property. Startup, as far as NMManager is concerned, is platform_query_devices(). However, the problem is that we only assume connections (contrary to doing external activation) when we have a connection-uuid from the state file or with guess-assume during startup. When assuming a master device, it can fail with (nm-bond): ignoring generated connection (IPv6LL-only and not in master-slave relationship) thus, for internal reason the device cannot be assumed yet. Fix that by attatching the assume-state to the device, so that on multiple recheck_assume_connection() calls we still try to assume. Whenever we try to assume the connection and it fails due to external reasons (like, the connection no longer matching), we clear the assume state, so that we only try as long as there are internal reasons why assuming fails. https://bugzilla.redhat.com/show_bug.cgi?id=1452062
2017-06-07 17:34:47 +02:00
nm_device_assume_state_reset (self);
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
_parent_set_ifindex (self, 0, FALSE);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
platform = nm_device_get_platform (self);
device: disconnect platform signal handlers first in dispose Once we start with dispose, we certainly don't want to process any platform events for the device anymore. Previously, we disconnect those handlers only later during dispose, so it's not clear that we would not receive a device_ipx_changed signal after _cleanup_generic_pre(). Fix this possible (or actual) bug.
2016-05-05 12:19:20 +02:00
g_signal_handlers_disconnect_by_func (platform, G_CALLBACK (device_ipx_changed), self);
g_signal_handlers_disconnect_by_func (platform, G_CALLBACK (link_changed_cb), self);
device: apply a loose IPv4 rp_filter when it would interfere with multihoming The IPv4 Strict Reverse Path Forwarding filter (RFC 3704) drops legitimate traffic when the same route is present on multiple interfaces, which is a pretty common scenario for IPv4 hosts. In particular, if the traffic is routable via multiple interfaces it drops traffic incoming via the device that has lower metric on the route to the originating network. Among other things, this disrupts existing connection when the user connected to the Internet via Wi-Fi activates a Wired Ethernet connection that also has a default route. Also, the Strict filter (and Reverse Path filters in general) provide practically no value to hosts that have a default route. The solution this patch uses is to detect scenarios where Strict filter is known to interfere and switch to a saner RP filter on the affected links. Routes to the same network on multiple interfaces is a good indication the RP filter would drop the legitimate traffice from the link with a lower metric. This includes the default routes. In such cases, we switch to the Loose Reverse Path Forwarding. This addresses the problems the multihomed hosts face, at the cost of disabling filtering altogether when a default route is present. A Feasible Path Reverse Path Forwarding would address the main problems with the Strict filter, but it's not implemented by the Linux kernel.
2017-03-16 14:27:03 +00:00
device: detect duplicate IPv4 addresses when method=manual
2015-12-23 14:15:05 +01:00
g_slist_free_full (priv->arping.dad_list, (GDestroyNotify) nm_arping_manager_destroy);
priv->arping.dad_list = NULL;
arp_cleanup (self);
device: re-apply sriov_numvfs after SIGHUP
2017-04-14 17:46:20 +02:00
nm_clear_g_signal_handler (nm_config_get (), &priv->config_changed_id);
device: allow reloading of the ignore-carrier flag Now on SIGHUP, when reloading NetworkManager configuration, also reload the ignore-carrier flag. While a device is activated, the reload is ignored until the device deactivates. Maybe it would be simpler just not to cache ignore_carrer and let it take effect immediately. But not caching ignore_carrer has the additional downside that every call to is_available must check the specs -- which in sum is potentially expensive for something that almost never changes. https://bugzilla.gnome.org/show_bug.cgi?id=748050
2015-04-17 14:12:10 +02:00
core: implement PRE_DOWN dispatcher actions (bgo #387832) https://bugzilla.gnome.org/show_bug.cgi?id=387832
2014-05-20 17:10:42 -05:00
dispatcher_cleanup (self);
proxy: introduce call-id for clearing pacmanager configuration nm_pacrunner_manager_remove() required a "tag" argument. It was a bug for callers trying to remove a configuration for a non-existing tag. That effectively means, the caller must keep track of whether a certain "tag" is pending. The caller also must remember the tag -- a tag that he must choose uniquely in the first place. Turn that around and have nm_pacrunner_manager_send() return a (non NULL) call-id. This call-id may later be used to remove the configuration. Apparently, previously the tracking of the "tag" was not always correct and we hit the assertion in nm_pacrunner_manager_remove(). https://bugzilla.redhat.com/show_bug.cgi?id=1444374
2017-04-21 15:46:56 +02:00
nm_pacrunner_manager_remove_clear (priv->pacrunner_manager,
&priv->pacrunner_call_id);
src: Fixes to add Proxy Feature src: Fixes in nm-device.c and nm-vpn-connection.c to update PacRunner at the right place and moment. When a device goes up PacRunner is configured with the Device IPxConfigs and Proxy Config. When it goes down the same configuration is removed from PacRunner. ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network scripts.
2016-08-16 05:55:58 +05:30
g_clear_object (&priv->pacrunner_manager);
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
_cleanup_generic_pre (self, CLEANUP_TYPE_KEEP);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
g_warn_if_fail (c_list_is_empty (&priv->slaves));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_assert (priv->master_ready_id == 0);
core: take over IPv6LL address management if kernel supports it (bgo #734149) NM keeps interfaces IFF_UP when possible to receive link layer events like carrier changes. Unfortunately, the kernel also uses IFF_UP as a flag to assign an IPv6LL address to the interface, which results in IPv6 connectivity on the link even if the interface is not supposed to be activated/connected. NM sets disable_ipv6=1 to ensure that the kernel does not set up IPv6LL connectivity on interfaces when they are not supposed to be active and connected. Unfortunately, that prevents users from manually adding IPv6 addresses to the interface, since they expect previous kernel behavior where IPv6 is enabled whenever the interface is IFF_UP. Furthermore, interfaces like PPP and some WWAN devices provide misleading information to the kernel which causes the kernel to create the wrong IPv6LL address for the interface. The IPv6LL address for these devices is obtained through control channels instead (IPV6CP for PPP, proprietary protocols for WWAN devices) and should be used instead of the kernel address. So we'd like to suppress kernel IPv6LL address generation on these interfaces anyway. This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE attribute to take over assignment of IPv6LL addresses while keeping the interface IFF_UP, to ensure there is only IPv6 connectivity when the user requests it. To remain compliant with standards, if a user adds IPv6 addresses externally, NetworkManager must also immediately add an IPv6LL address for that interface too. https://bugzilla.gnome.org/show_bug.cgi?id=734149
2014-07-24 17:14:30 -05:00
/* Let the kernel manage IPv6LL again */
set_nm_ipv6ll (self, FALSE);
device: fix cleanup DHCP instance when unmanaging device on removed platform link When the platform link gets removed outside of NetworkManager, we would unmanage the device first. By checking the device state reason NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the interface, as it is already gone. This was not correct because we must at least stop the dhcp client. Otherwise the dhclient process keeps running. That meant, if the device reappeared later, we would start dhclient again. Then we would find the PID of the still running instance in the pidfile and kill it only than. Fix it by replacing the 'deconfigure' boolean by a tri-state 'cleanup_type'.
2015-06-30 16:13:03 +02:00
_cleanup_generic_post (self, CLEANUP_TYPE_KEEP);
core: allow devices to specify a DHCP anycast address Relevant only for OLPC at this point; the mesh device uses it to target DHCP requests at a pre-defined mesh portal anycast address.
2009-07-15 13:53:49 -04:00
device: refactor dispose/cleanup of NMDevice to free members in finalize NMTestDevice does not invoke dispose(), hence it leaks memory which causes false warnings in testing. Some minor refactring to let dispose() clear the fields, but free it later in finalize(). This avoids memleaks in the NMTestDevice stub.
2015-02-08 10:07:11 +01:00
g_hash_table_remove_all (priv->ip6_saved_properties);
core: allow devices to specify a DHCP anycast address Relevant only for OLPC at this point; the mesh device uses it to target DHCP requests at a pre-defined mesh portal anycast address.
2009-07-15 13:53:49 -04:00
core,libnm: use nm_clear_g_source() where possible Replacement was done with commands: spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir src spatch --sp-file nm_clear_g_source.cocci --in-place --smpl-spacing --dir libnm where nm_clear_g_source.cocci contains: @@ expression e; @@ - if (e) { - g_source_remove (e); - e = 0; - } + nm_clear_g_source (&e);
2016-01-04 09:46:22 +01:00
nm_clear_g_source (&priv->recheck_assume_id);
nm_clear_g_source (&priv->recheck_available.call_id);
core: add generic NMDevice function to recheck availability And use it everywhere.
2015-04-13 17:16:55 -05:00
device: remove unrealized device without connections on idle handler Emitting the NM_DEVICE_REMOVED signal can cause the destruction of the device, thus it should be emitted on an idle handler.
2016-01-19 11:33:33 +01:00
nm_clear_g_source (&priv->check_delete_unrealized_id);
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
nm_clear_g_source (&priv->stats.timeout_id);
device/trivial: rename functions related to "carrier"
2017-05-12 16:21:55 +02:00
carrier_disconnected_action_cancel (self);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
if (priv->ifindex > 0) {
priv->ifindex = 0;
_notify (self, PROP_IFINDEX);
}
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
if (priv->settings) {
g_signal_handlers_disconnect_by_func (priv->settings, cp_connection_added, self);
g_signal_handlers_disconnect_by_func (priv->settings, cp_connection_updated, self);
g_signal_handlers_disconnect_by_func (priv->settings, cp_connection_removed, self);
core: allow devices to specify a DHCP anycast address Relevant only for OLPC at this point; the mesh device uses it to target DHCP requests at a pre-defined mesh portal anycast address.
2009-07-15 13:53:49 -04:00
}
device: cleanup handling available-connections For update, don't delete first and add it again. Just do it in one step. For recheck, don't delete all connections first to add them all anew. Instead, check what changes and only emit the changed signal if there are any actual changes.
2016-01-20 17:44:50 +01:00
available_connections_del_all (self);
core: add "Autoconnect" property to NMDevice It is bound to autoconnect_inhibit private variable (has opposite meaning). While 'Autoconnect' is TRUE (default value) the device can automatically activate a connection. If it is changed to FALSE, the device will not auto-activate until 'Autoconnect' is TRUE again. Disconnect() method sets 'Autoconnect' to FALSE. NMPolicy monitors the property and schedules auto activation when FALSE->TRUE transition is made.
2012-05-14 15:32:54 +02:00
device: fix delaying startup complete waiting for carrier platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ... ... device[0x7f90c29c64d0] (eth0): bringing up device ... platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ... ... device (eth0): link connected ... device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait' Note how we schedule the pending action 'carrier-wait', although the device already has carrier. That means, the pending action will not be removed until timeout, 5 seconds later. Avoid scheduling 'carrier-wait' if we already have carrier. However, don't just add the pending action 'carrier-wait' only during nm_device_bring_up(). Instead, always schedule the carrier_wait timeout. This gives a grace period during which we keep setting 'carrier-wait' whenever we have no carrier. This should prevent two cases: - during nm_device_bring_up() the platform state might not yet have caught up. If we don't add the pending action there, we will add it a moment later when carrier goes away. - bringing the interface up might cause carrier to get lost for a moment (flapping). If that happens within the timeout, also add the pending action.
2017-05-12 16:32:15 +02:00
if (nm_clear_g_source (&priv->carrier_wait_id))
nm_device_remove_pending_action (self, NM_PENDING_ACTION_CARRIER_WAIT, FALSE);
core: implement manual disconnect feature In the past networkmanager did not allow to manually disconnect devices. Manually disconnected devices will not be automatically reconnected until one of the following events occur: 1. user activates a connection for the currently disconnected device 2. network manager awakes from hibernate/suspend 3. network manager is restarted (e.g. reboot) Add a Disconnect method to generic NMDevice dbus interface; set a new private autoconnect_inhibit flag if Disconnect method is called through dbus. Based on this auto activation for devices gets inhibited until one of the above events occur.
2009-09-16 13:18:24 +02:00
device: fix leaking queued NMActiveConnection The queued activation request must transition state to DEACTIVATED, otherwise it is not removed from the list of active_connections in NMManager.
2015-02-20 23:45:23 +01:00
_clear_queued_act_request (priv);
wifi: bypass available check for hidden APs during activation (rh #1069844) Because not all clients set the 'hidden' property in a connection for hidden/non-SSID-broadcasting networks, they may not show up in the device's available-connections property. After the PendingActivation object removal, all activations require the connection to be in available-connections, and thus hidden SSID networks could not be activated. Unfortunately check_connection_available() is used both during activation and to populate the available-connections array, but we only want to special-case activation paths, and still ensure that SSIDs not found in the scan list are not in available-connections. To make it clear this is a WiFi only hack, and that we should remove it at some point in the future, create another class method specifically for hidden WiFi and use that in activation paths to special-case hidden WiFi connection activation.
2014-03-05 10:16:39 -06:00
device: delay handling of link-changed platform event When inside a state-change, we set for example the device up. This triggers a link-changed event, which then causes further state-changes of the devices. A state-change in process of a device is not reentrant, so we must delay the handling of the link-changed event.
2015-06-17 19:13:08 +02:00
nm_clear_g_source (&priv->device_link_changed_id);
nm_clear_g_source (&priv->device_ip_link_changed_id);
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
if (priv->lldp_listener) {
g_signal_handlers_disconnect_by_func (priv->lldp_listener,
G_CALLBACK (lldp_neighbors_changed),
self);
nm_lldp_listener_stop (priv->lldp_listener);
g_clear_object (&priv->lldp_listener);
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
G_OBJECT_CLASS (nm_device_parent_class)->dispose (object);
device: clear queued_state callback in dispose dispose() calls _cleanup_generic_pre() which in turn already calls nm_device_queued_state_clear(). So we would expect that at the end of dispose() no queued-state is pending. However, there there are crashes reports in queued_set_state() with the device instance already destructed (rh#1270247). Add this check trying to avoid the crash and closing in on the cause. Related: https://bugzilla.redhat.com/show_bug.cgi?id=1180827 Related: https://bugzilla.redhat.com/show_bug.cgi?id=1270247 Related: https://bugzilla.redhat.com/show_bug.cgi?id=1298009
2016-01-19 12:53:34 +01:00
if (nm_clear_g_source (&priv->queued_state.id)) {
/* FIXME: we'd expect the queud_state to be alredy cleared and this statement
* not being necessary. Add this check here to hopefully investigate crash
* rh#1270247. */
g_return_if_reached ();
}
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
}
static void
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
finalize (GObject *object)
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
{
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
NMDevice *self = NM_DEVICE (object);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
core: refactoring logging in NMDevice to use new _LOG() macros Make use of the previously added _LOG() macros in nm-device.c. This reduces code, but also ensures printing the same prefix for every logline produced *for* a device instance. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-02-12 23:54:26 +01:00
_LOGD (LOGD_DEVICE, "finalize(): %s", G_OBJECT_TYPE_NAME (self));
core: update data types of some hwaddr properties Now that we have nm_utils_hwaddr_matches() for comparing addresses (even when one is a string and the other binary), there are now places where it's more convenient to store hardware addresses as strings rather than binary, since we want them in string form for most non-comparison purposes. So update for that. In particular, this also changes nm_device_get_hw_address() to return a string. Also, simplify the update_permanent_hw_address() implementations by assuming that they will only be called once. (Since they will.)
2014-06-21 12:44:56 -04:00
g_free (priv->hw_addr);
device/trivial: rename hw-addr related fields in NMDevicePrivate Next I will add two more fields. Being able to efficiently grep the code is important. I want to be able to grep for "->hw_addr" or "\<hw_addr" to find related stuff. Unfortunately, prefixes often result in backward English names, e.g. hw_addr_set/hw_addr_get. I still prefer that over get_hw_addr/set_hw_addr though.
2016-06-03 13:37:08 +02:00
g_free (priv->hw_addr_perm);
g_free (priv->hw_addr_initial);
device: don't clone pending-action string All callers either use a static @action argument or keep a clone of the string that lives as long as the action is pending. So, save cloning the string.
2017-01-27 15:41:25 +01:00
g_slist_free (priv->pending_actions);
core: support IPv6 duplicate address detection NMDevice detects the DAD failures by watching the removal of tentative addresses (happens for DAD of addresses with valid lifetime, typically discovered addresses) or changes to addresses with dadfailed flag (permanent addresses, typically link-local and manually configured addresses). It retries creation of link-local addresses itself and lets RDisc know about the rest so that it can decide if it's rdisc-managed address and retry with a new address. Currently NMDevice doesn't do anything useful about link-local address DAD failures -- it just fails the link-local address addition instead of just timing out, which happened before. RDisc just logs a warning and removes the address from the list. However, with RFC7217 stable privacy addresses the use of a different address and thus a recovery from DAD failures would be possible.
2015-10-03 19:50:30 +02:00
g_slist_free_full (priv->dad6_failed_addrs, g_free);
core: (trivial) some NMDevice dispose/finalize cleanups Ensure autoip4 is cleaned up when disposing, like we clean up DHCP. Move things that only free stuff to finalize(), and move things that unref stuff to dispose (eg, the Firewall Manager stuff).
2014-05-22 14:04:01 -05:00
g_clear_pointer (&priv->physical_port_id, g_free);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_free (priv->udi);
g_free (priv->iface);
g_free (priv->ip_iface);
g_free (priv->driver);
g_free (priv->driver_version);
g_free (priv->firmware_version);
g_free (priv->type_desc);
device: add nm_device_get_type_description() function Add a function to get a concise representation of the device type. libnm already has nm_device_get_type_description() for that and it is shown by nmcli -f GENERAL.TYPE device show Reimplement that function for nm-core. Just take care that the two implementations don't diverge.
2015-05-15 15:00:07 +02:00
g_free (priv->type_description);
libnm-core: change all mac-address properties to G_TYPE_STRING Make all mac-address properties (including NMSettingBluetooth:bdaddr, NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be strings, using _nm_setting_class_transform_property() to handle translating to/from binary form when dealing with D-Bus. Update everything accordingly for the change, and also add a test for transformed setting properties to test-general.
2014-07-30 10:57:45 -04:00
g_free (priv->dhcp_anycast_address);
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
g_free (priv->current_stable_id);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
device: refactor dispose/cleanup of NMDevice to free members in finalize NMTestDevice does not invoke dispose(), hence it leaks memory which causes false warnings in testing. Some minor refactring to let dispose() clear the fields, but free it later in finalize(). This avoids memleaks in the NMTestDevice stub.
2015-02-08 10:07:11 +01:00
g_hash_table_unref (priv->ip6_saved_properties);
g_hash_table_unref (priv->available_connections);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
G_OBJECT_CLASS (nm_device_parent_class)->finalize (object);
device: use NMSettings directly instead of NMConnectionProvider
2016-05-16 18:40:44 +02:00
/* for testing, NMDeviceTest does not invoke NMDevice::constructed,
* and thus @settings might be unset. */
if (priv->settings)
g_object_unref (priv->settings);
device: keep NMNetns instance per device This also ensures that we own a reference to the NMPlatform, NMRouteManager and NMDefaultRouteManager instances. See bug rh#1440089 where we might access the singleton getter after destroing the singleton instance of NMRouteManager. This is prevented by keeping a reference to those instances -- indirectly via the netns instance. Later, we may add support for multiple namespaces. Then it might make sense to swap the NMNetns instance of a device when moving the device between namespaces. Also, drop the use of singelton instances. https://bugzilla.redhat.com/show_bug.cgi?id=1440089
2017-04-17 20:17:45 +02:00
g_object_unref (priv->netns);
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
set_property (GObject *object, guint prop_id,
const GValue *value, GParamSpec *pspec)
core: rework ignore-carrier device behavior Previously, ignore-carrier devices were always in the unavailable state until they were activated. This required some complicated code to keep track of whether the device was available or not based on what connections existed, whether those connections were static-IP, and whether the device was ignore-carrier. Various bits of the code used nm_device_can_activate() for two different purposes: (1) to determine if the device was available on an L2 basis, which nm_device_can_activate() wasn't well-suited to, and (2) whether a specific connection could be activated at a given time based on ignore-carrier and whether the connection was static IP or not. Remove that complexity and confusion by making ignore-carrier devices always move to DISCONNECTED state, and simply refuse to activate connections that require connectivity, but allow connections that don't require connectivity. Also, when the device has no carrier, don't add connections that require connectivity to the AvailableConnections device property.
2013-11-04 19:51:28 -06:00
{
device: initialize NMDevice's hw_addr at end of object construction hw-addr is a constuct-only property. We should not do complex stuff in the property setter before the object is sufficiently initialized. For example, the logging macros access nm_device_get_iface(), which might be unset at that early point. Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor() function. Also, ensure that @hw_addr_len is zero iff @hw_addr is unset. Also, ensure that we always log a message when changing/setting the hardware address -- except when clearing it during unrealize. It's implicit that unrealize clears the hardware address. Also, give all related logging messages a "hw-addr:" prefix.
2016-05-20 12:34:13 +02:00
NMDevice *self = (NMDevice *) object;
core/trivial: change variable name for self pointer in NMDevice to @self Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-15 13:36:24 +02:00
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
device: add nm_device_get_type_description() function Add a function to get a concise representation of the device type. libnm already has nm_device_get_type_description() for that and it is shown by nmcli -f GENERAL.TYPE device show Reimplement that function for nm-core. Just take care that the two implementations don't diverge.
2015-05-15 15:00:07 +02:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
switch (prop_id) {
case PROP_UDI:
device: make UDI property construct-only
2017-05-17 15:01:10 +02:00
/* construct-only */
priv->udi = g_value_dup_string (value);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_IFACE:
device: initialize nm_plugin_missing via constructor property No need for the setter/getter of this property. Immutable properties are so much nicer. Remove the setter and ensure that the nm_plugin_missing property is only set during object construction.
2016-09-26 13:26:15 +02:00
/* construct-only */
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
priv->iface = g_value_dup_string (value);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_DRIVER:
device: mark properties in set_property() as construct-only (cherry picked from commit ba47744997091562ad1844c28d07a6de16a7c0bf)
2017-01-20 17:33:44 +01:00
/* construct-only */
priv->driver = g_value_dup_string (value);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_DRIVER_VERSION:
device: mark properties in set_property() as construct-only (cherry picked from commit ba47744997091562ad1844c28d07a6de16a7c0bf)
2017-01-20 17:33:44 +01:00
/* construct-only */
all: trivial: use g_value_dup_string ()
2016-05-30 16:11:28 +02:00
priv->driver_version = g_value_dup_string (value);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_FIRMWARE_VERSION:
device: mark properties in set_property() as construct-only (cherry picked from commit ba47744997091562ad1844c28d07a6de16a7c0bf)
2017-01-20 17:33:44 +01:00
/* construct-only */
all: trivial: use g_value_dup_string ()
2016-05-30 16:11:28 +02:00
priv->firmware_version = g_value_dup_string (value);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_IP4_ADDRESS:
priv->ip4_address = g_value_get_uint (value);
break;
device: forget unmanaged-flag "user-explicit" for unrealized devices When a software device unrealizes, we want to forget about the "user-explict" unmanaged state. It means, that after a software device is deleted, the "user-explict" managed flag will be cleared for that device. It might be nice to preserve the managed-state after deletion of the device. However, the unrealized-device only exists as long as we have a connection for the device. That means, before this patch whether the unmanaged flag was forgotten depends on whether the user had some connections that keep the device alive as unrealized. That behavior was complicated, just don't do that.
2016-08-30 14:58:52 +02:00
case PROP_MANAGED:
if (nm_device_is_real (self)) {
gboolean managed;
NMDeviceStateReason reason;
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
device: forget unmanaged-flag "user-explicit" for unrealized devices When a software device unrealizes, we want to forget about the "user-explict" unmanaged state. It means, that after a software device is deleted, the "user-explict" managed flag will be cleared for that device. It might be nice to preserve the managed-state after deletion of the device. However, the unrealized-device only exists as long as we have a connection for the device. That means, before this patch whether the unmanaged flag was forgotten depends on whether the user had some connections that keep the device alive as unrealized. That behavior was complicated, just don't do that.
2016-08-30 14:58:52 +02:00
managed = g_value_get_boolean (value);
device: when setting back a device to managed, update internal sys state Otherwise a device which was set as unmanaged (updated to the REMOVED internal sys-state) will never update its own sys-state if later set back as managed. Manage either when setting explictly the device to managed either when just upping a connection on an unmanaged device.
2017-05-19 17:34:23 +02:00
if (managed) {
device: forget unmanaged-flag "user-explicit" for unrealized devices When a software device unrealizes, we want to forget about the "user-explict" unmanaged state. It means, that after a software device is deleted, the "user-explict" managed flag will be cleared for that device. It might be nice to preserve the managed-state after deletion of the device. However, the unrealized-device only exists as long as we have a connection for the device. That means, before this patch whether the unmanaged flag was forgotten depends on whether the user had some connections that keep the device alive as unrealized. That behavior was complicated, just don't do that.
2016-08-30 14:58:52 +02:00
reason = NM_DEVICE_STATE_REASON_CONNECTION_ASSUMED;
device: when setting back a device to managed, update internal sys state Otherwise a device which was set as unmanaged (updated to the REMOVED internal sys-state) will never update its own sys-state if later set back as managed. Manage either when setting explictly the device to managed either when just upping a connection on an unmanaged device.
2017-05-19 17:34:23 +02:00
if (NM_IN_SET_TYPED (NMDeviceSysIfaceState,
priv->sys_iface_state,
NM_DEVICE_SYS_IFACE_STATE_EXTERNAL,
NM_DEVICE_SYS_IFACE_STATE_REMOVED))
nm_device_sys_iface_state_set (self, NM_DEVICE_SYS_IFACE_STATE_ASSUME);
} else {
device: forget unmanaged-flag "user-explicit" for unrealized devices When a software device unrealizes, we want to forget about the "user-explict" unmanaged state. It means, that after a software device is deleted, the "user-explict" managed flag will be cleared for that device. It might be nice to preserve the managed-state after deletion of the device. However, the unrealized-device only exists as long as we have a connection for the device. That means, before this patch whether the unmanaged flag was forgotten depends on whether the user had some connections that keep the device alive as unrealized. That behavior was complicated, just don't do that.
2016-08-30 14:58:52 +02:00
reason = NM_DEVICE_STATE_REASON_REMOVED;
device: leave device up when setting it as unmanaged by user Before, setting a device to unmanaged causes it to go down and clear the interface state. It may be useful to instruct NetworkManager not to touch the device anymore but leave the current state up. Changing behavior for nmcli device set "$DEV" managed no To get the previous behavior, one has to first disconnect the interface via nmcli device disconnect "$DEV" nmcli device set "$DEV" managed no Note that non-permanent addresses like from DHCP will eventually time out because NetworkManager stops the DHCP client. When instructing NetworkManager to let go of the device, you have to take it over in any way you see fit. https://bugzilla.redhat.com/show_bug.cgi?id=1371433
2017-04-18 14:46:27 +02:00
nm_device_sys_iface_state_set (self, NM_DEVICE_SYS_IFACE_STATE_REMOVED);
}
device: forget unmanaged-flag "user-explicit" for unrealized devices When a software device unrealizes, we want to forget about the "user-explict" unmanaged state. It means, that after a software device is deleted, the "user-explict" managed flag will be cleared for that device. It might be nice to preserve the managed-state after deletion of the device. However, the unrealized-device only exists as long as we have a connection for the device. That means, before this patch whether the unmanaged flag was forgotten depends on whether the user had some connections that keep the device alive as unrealized. That behavior was complicated, just don't do that.
2016-08-30 14:58:52 +02:00
nm_device_set_unmanaged_by_flags (self,
NM_UNMANAGED_USER_EXPLICIT,
!managed,
reason);
}
device: allow modifying Managed property https://bugzilla.redhat.com/show_bug.cgi?id=1114685 https://bugzilla.gnome.org/show_bug.cgi?id=746566 Related: https://bugzilla.gnome.org/show_bug.cgi?id=680909 Related: https://bugzilla.gnome.org/show_bug.cgi?id=731014 Based-on-patch-by: Lubomir Rintel <lkundrak@v3.sk>
2015-09-15 14:27:31 +02:00
break;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
case PROP_AUTOCONNECT:
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
if (g_value_get_boolean (value))
nm_device_autoconnect_blocked_unset (self, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL);
else
nm_device_autoconnect_blocked_set (self, NM_DEVICE_AUTOCONNECT_BLOCKED_USER);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_FIRMWARE_MISSING:
device: initialize nm_plugin_missing via constructor property No need for the setter/getter of this property. Immutable properties are so much nicer. Remove the setter and ensure that the nm_plugin_missing property is only set during object construction.
2016-09-26 13:26:15 +02:00
/* construct-only */
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv->firmware_missing = g_value_get_boolean (value);
break;
device: add nm-plugin-missing property indicating NM device plugin not available It is useful for indicating that the device type is supported but the required plugin is not installed.
2015-04-14 14:16:04 +02:00
case PROP_NM_PLUGIN_MISSING:
device: initialize nm_plugin_missing via constructor property No need for the setter/getter of this property. Immutable properties are so much nicer. Remove the setter and ensure that the nm_plugin_missing property is only set during object construction.
2016-09-26 13:26:15 +02:00
/* construct-only */
device: add nm-plugin-missing property indicating NM device plugin not available It is useful for indicating that the device type is supported but the required plugin is not installed.
2015-04-14 14:16:04 +02:00
priv->nm_plugin_missing = g_value_get_boolean (value);
break;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
case PROP_DEVICE_TYPE:
device: mark properties in set_property() as construct-only (cherry picked from commit ba47744997091562ad1844c28d07a6de16a7c0bf)
2017-01-20 17:33:44 +01:00
/* construct-only */
nm_assert (priv->type == NM_DEVICE_TYPE_UNKNOWN);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv->type = g_value_get_uint (value);
break;
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
case PROP_LINK_TYPE:
device: initialize nm_plugin_missing via constructor property No need for the setter/getter of this property. Immutable properties are so much nicer. Remove the setter and ensure that the nm_plugin_missing property is only set during object construction.
2016-09-26 13:26:15 +02:00
/* construct-only */
device: mark properties in set_property() as construct-only (cherry picked from commit ba47744997091562ad1844c28d07a6de16a7c0bf)
2017-01-20 17:33:44 +01:00
nm_assert (priv->link_type == NM_LINK_TYPE_NONE);
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
priv->link_type = g_value_get_uint (value);
break;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
case PROP_TYPE_DESC:
device: mark properties in set_property() as construct-only (cherry picked from commit ba47744997091562ad1844c28d07a6de16a7c0bf)
2017-01-20 17:33:44 +01:00
/* construct-only */
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv->type_desc = g_value_dup_string (value);
break;
case PROP_RFKILL_TYPE:
device: mark properties in set_property() as construct-only (cherry picked from commit ba47744997091562ad1844c28d07a6de16a7c0bf)
2017-01-20 17:33:44 +01:00
/* construct-only */
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
priv->rfkill_type = g_value_get_uint (value);
break;
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
case PROP_PERM_HW_ADDRESS:
device: initialize nm_plugin_missing via constructor property No need for the setter/getter of this property. Immutable properties are so much nicer. Remove the setter and ensure that the nm_plugin_missing property is only set during object construction.
2016-09-26 13:26:15 +02:00
/* construct-only */
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
priv->hw_addr_perm = g_value_dup_string (value);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
device: drop nm-device-statistics.c and refactor tracking device statistics Originally, "nm-device-statistics.c" contained code to fetch the device counters via netlink. As now the netlink part is handled by NMPlatform, the code can be simplified by merging it back to NMDevice.
2016-08-16 12:10:23 +02:00
case PROP_REFRESH_RATE_MS:
_stats_set_refresh_rate (self, g_value_get_uint (value));
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
break;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
core: rework ignore-carrier device behavior Previously, ignore-carrier devices were always in the unavailable state until they were activated. This required some complicated code to keep track of whether the device was available or not based on what connections existed, whether those connections were static-IP, and whether the device was ignore-carrier. Various bits of the code used nm_device_can_activate() for two different purposes: (1) to determine if the device was available on an L2 basis, which nm_device_can_activate() wasn't well-suited to, and (2) whether a specific connection could be activated at a given time based on ignore-carrier and whether the connection was static IP or not. Remove that complexity and confusion by making ignore-carrier devices always move to DISCONNECTED state, and simply refuse to activate connections that require connectivity, but allow connections that don't require connectivity. Also, when the device has no carrier, don't add connections that require connectivity to the AvailableConnections device property.
2013-11-04 19:51:28 -06:00
}
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
get_property (GObject *object, guint prop_id,
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
GValue *value, GParamSpec *pspec)
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
{
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
NMDevice *self = NM_DEVICE (object);
NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
GPtrArray *array;
GHashTableIter iter;
NMConnection *connection;
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
GVariantBuilder array_builder;
core: rework ignore-carrier device behavior Previously, ignore-carrier devices were always in the unavailable state until they were activated. This required some complicated code to keep track of whether the device was available or not based on what connections existed, whether those connections were static-IP, and whether the device was ignore-carrier. Various bits of the code used nm_device_can_activate() for two different purposes: (1) to determine if the device was available on an L2 basis, which nm_device_can_activate() wasn't well-suited to, and (2) whether a specific connection could be activated at a given time based on ignore-carrier and whether the connection was static IP or not. Remove that complexity and confusion by making ignore-carrier devices always move to DISCONNECTED state, and simply refuse to activate connections that require connectivity, but allow connections that don't require connectivity. Also, when the device has no carrier, don't add connections that require connectivity to the AvailableConnections device property.
2013-11-04 19:51:28 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
switch (prop_id) {
case PROP_UDI:
device: sanitze UTF-8 values for D-Bus ip link add name $'d\xccf\\c' type dummy Use nm_utils_str_utf8safe_escape() to sanitize non UTF-8 sequences before exposing them on D-Bus. The operation can be reverted client side via nm_utils_str_utf8safe_unescape() or simply g_strcompress(). Note that this preserves all valid UTF-8 sequences as-is, with exception of the backslash escape character and ASCII control characters. Thus, this is a change in behavior for strings that contain such characters. Note that nmcli is not changed to somehow unescape the string before printing. As the string is not valid UTF-8 (or contains ASCII characters that need escaping), they are not printable as-is, so unescaping before printing makes little sense.
2017-05-16 14:11:07 +02:00
/* UDI is (depending on the device type) a path to sysfs and can contain
* non-UTF-8.
* ip link add name $'d\xccf\\c' type dummy */
g_value_take_string (value,
nm_utils_str_utf8safe_escape_cp (priv->udi,
NM_UTILS_STR_UTF8_SAFE_FLAG_NONE));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_IFACE:
device: sanitze UTF-8 values for D-Bus ip link add name $'d\xccf\\c' type dummy Use nm_utils_str_utf8safe_escape() to sanitize non UTF-8 sequences before exposing them on D-Bus. The operation can be reverted client side via nm_utils_str_utf8safe_unescape() or simply g_strcompress(). Note that this preserves all valid UTF-8 sequences as-is, with exception of the backslash escape character and ASCII control characters. Thus, this is a change in behavior for strings that contain such characters. Note that nmcli is not changed to somehow unescape the string before printing. As the string is not valid UTF-8 (or contains ASCII characters that need escaping), they are not printable as-is, so unescaping before printing makes little sense.
2017-05-16 14:11:07 +02:00
g_value_take_string (value,
nm_utils_str_utf8safe_escape_cp (priv->iface,
NM_UTILS_STR_UTF8_SAFE_FLAG_ESCAPE_CTRL));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_IP_IFACE:
device: sanitze UTF-8 values for D-Bus ip link add name $'d\xccf\\c' type dummy Use nm_utils_str_utf8safe_escape() to sanitize non UTF-8 sequences before exposing them on D-Bus. The operation can be reverted client side via nm_utils_str_utf8safe_unescape() or simply g_strcompress(). Note that this preserves all valid UTF-8 sequences as-is, with exception of the backslash escape character and ASCII control characters. Thus, this is a change in behavior for strings that contain such characters. Note that nmcli is not changed to somehow unescape the string before printing. As the string is not valid UTF-8 (or contains ASCII characters that need escaping), they are not printable as-is, so unescaping before printing makes little sense.
2017-05-16 14:11:07 +02:00
if (ip_config_valid (priv->state)) {
g_value_take_string (value,
nm_utils_str_utf8safe_escape_cp (nm_device_get_ip_iface (self),
NM_UTILS_STR_UTF8_SAFE_FLAG_ESCAPE_CTRL));
} else
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_value_set_string (value, NULL);
break;
case PROP_IFINDEX:
g_value_set_int (value, priv->ifindex);
break;
case PROP_DRIVER:
device: sanitze UTF-8 values for D-Bus ip link add name $'d\xccf\\c' type dummy Use nm_utils_str_utf8safe_escape() to sanitize non UTF-8 sequences before exposing them on D-Bus. The operation can be reverted client side via nm_utils_str_utf8safe_unescape() or simply g_strcompress(). Note that this preserves all valid UTF-8 sequences as-is, with exception of the backslash escape character and ASCII control characters. Thus, this is a change in behavior for strings that contain such characters. Note that nmcli is not changed to somehow unescape the string before printing. As the string is not valid UTF-8 (or contains ASCII characters that need escaping), they are not printable as-is, so unescaping before printing makes little sense.
2017-05-16 14:11:07 +02:00
g_value_take_string (value,
nm_utils_str_utf8safe_escape_cp (priv->driver,
NM_UTILS_STR_UTF8_SAFE_FLAG_ESCAPE_CTRL));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_DRIVER_VERSION:
device: sanitze UTF-8 values for D-Bus ip link add name $'d\xccf\\c' type dummy Use nm_utils_str_utf8safe_escape() to sanitize non UTF-8 sequences before exposing them on D-Bus. The operation can be reverted client side via nm_utils_str_utf8safe_unescape() or simply g_strcompress(). Note that this preserves all valid UTF-8 sequences as-is, with exception of the backslash escape character and ASCII control characters. Thus, this is a change in behavior for strings that contain such characters. Note that nmcli is not changed to somehow unescape the string before printing. As the string is not valid UTF-8 (or contains ASCII characters that need escaping), they are not printable as-is, so unescaping before printing makes little sense.
2017-05-16 14:11:07 +02:00
g_value_take_string (value,
nm_utils_str_utf8safe_escape_cp (priv->driver_version,
NM_UTILS_STR_UTF8_SAFE_FLAG_ESCAPE_CTRL));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_FIRMWARE_VERSION:
device: sanitze UTF-8 values for D-Bus ip link add name $'d\xccf\\c' type dummy Use nm_utils_str_utf8safe_escape() to sanitize non UTF-8 sequences before exposing them on D-Bus. The operation can be reverted client side via nm_utils_str_utf8safe_unescape() or simply g_strcompress(). Note that this preserves all valid UTF-8 sequences as-is, with exception of the backslash escape character and ASCII control characters. Thus, this is a change in behavior for strings that contain such characters. Note that nmcli is not changed to somehow unescape the string before printing. As the string is not valid UTF-8 (or contains ASCII characters that need escaping), they are not printable as-is, so unescaping before printing makes little sense.
2017-05-16 14:11:07 +02:00
g_value_take_string (value,
nm_utils_str_utf8safe_escape_cp (priv->firmware_version,
NM_UTILS_STR_UTF8_SAFE_FLAG_ESCAPE_CTRL));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_CAPABILITIES:
g_value_set_uint (value, (priv->capabilities & ~NM_DEVICE_CAP_INTERNAL_MASK));
break;
case PROP_IP4_ADDRESS:
g_value_set_uint (value, priv->ip4_address);
break;
case PROP_CARRIER:
g_value_set_boolean (value, priv->carrier);
break;
case PROP_MTU:
g_value_set_uint (value, priv->mtu);
break;
case PROP_IP4_CONFIG:
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
nm_utils_g_value_set_object_path (value, ip_config_valid (priv->state) ? priv->ip4_config : NULL);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_DHCP4_CONFIG:
device: group DHCP4 private members
2016-04-07 14:34:31 +02:00
nm_utils_g_value_set_object_path (value, ip_config_valid (priv->state) ? priv->dhcp4.config : NULL);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_IP6_CONFIG:
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
nm_utils_g_value_set_object_path (value, ip_config_valid (priv->state) ? priv->ip6_config : NULL);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_DHCP6_CONFIG:
device: group DHCP6 private members
2016-04-07 14:45:57 +02:00
nm_utils_g_value_set_object_path (value, ip_config_valid (priv->state) ? priv->dhcp6.config : NULL);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_STATE:
g_value_set_uint (value, priv->state);
break;
case PROP_STATE_REASON:
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
g_value_take_variant (value,
g_variant_new ("(uu)", priv->state, priv->state_reason));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_ACTIVE_CONNECTION:
device: track exported-object path for NMActRequest from device 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 9ae5e6a54d1904932ce300b57d9953bd3be2f4a9)
2017-01-24 19:43:52 +01:00
nm_utils_g_value_set_object_path (value, priv->act_request_public ? priv->act_request : NULL);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_DEVICE_TYPE:
g_value_set_uint (value, priv->type);
break;
device: add link_type property This is to make it possible for the device factories to indicate the desired link type and make it possible to avoid matching the unrealized device to a platform device of different link type.
2015-12-08 14:49:50 +01:00
case PROP_LINK_TYPE:
g_value_set_uint (value, priv->link_type);
break;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
case PROP_MANAGED:
device: remove default-unmanaged and refactor unmanaged flags Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between unmanaged flags, device state and managed property. Previously, the NM_UNMANAGED_DEFAULT was special in that a device was still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag set and its state was managed. Thus, whether the device (state) was managed, depended on the device state too. Now, a device is considered managed (or unmanaged) based on the unmanaged flags and realization state alone. At the same time, the device state directly corresponds to the managed property of the device. Of course, while changing the unmanaged flags, that invariant is shortly violated until the state transistion is complete. Introduce more unmanaged flags whereas some of them are non-authorative. For example, the EXTERNAL_DOWN flag has only effect as long as the user didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other words, certain flags can render other flags ineffective. Whether the device is considered managed depends on the flags but also at the explicitly unset flags. In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored (if no other flags were present). Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected state would transition back to unmanaged. No longer do that. Once a device is managed, it stays managed as long as the flags indicate it should be managed. However, the user can also modify the unmanaged flags via the D-Bus API. Also get rid or nm_device_finish_init(). That was previously called by NMManager after add_device(). As we now realize devices (possibly multiple times) this should be handled during realization. https://bugzilla.gnome.org/show_bug.cgi?id=746566
2015-09-15 15:35:16 +02:00
/* The managed state exposed on D-Bus only depends on the current device state alone. */
g_value_set_boolean (value, nm_device_get_state (self) > NM_DEVICE_STATE_UNMANAGED);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_AUTOCONNECT:
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
2017-11-07 10:48:55 +01:00
g_value_set_boolean (value,
nm_device_autoconnect_blocked_get (self, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)
? FALSE
: TRUE);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_FIRMWARE_MISSING:
g_value_set_boolean (value, priv->firmware_missing);
break;
device: add nm-plugin-missing property indicating NM device plugin not available It is useful for indicating that the device type is supported but the required plugin is not installed.
2015-04-14 14:16:04 +02:00
case PROP_NM_PLUGIN_MISSING:
g_value_set_boolean (value, priv->nm_plugin_missing);
break;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
case PROP_TYPE_DESC:
g_value_set_string (value, priv->type_desc);
break;
case PROP_RFKILL_TYPE:
g_value_set_uint (value, priv->rfkill_type);
break;
case PROP_AVAILABLE_CONNECTIONS:
array = g_ptr_array_sized_new (g_hash_table_size (priv->available_connections));
g_hash_table_iter_init (&iter, priv->available_connections);
while (g_hash_table_iter_next (&iter, (gpointer) &connection, NULL))
g_ptr_array_add (array, g_strdup (nm_connection_get_path (connection)));
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
g_ptr_array_add (array, NULL);
g_value_take_boxed (value, (char **) g_ptr_array_free (array, FALSE));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
case PROP_PHYSICAL_PORT_ID:
g_value_set_string (value, priv->physical_port_id);
break;
case PROP_MASTER:
device: let NM_DEVICE_MASTER be equal to nm_device_get_master() There is only one user of the NM_DEVICE_MASTER property (NMActiveConnection). device_master_changed() uses the property for change notifications, but returns early if !nm_device_get_master(). We might emit the "notify::master" signal too often, even when nothing changed (because currently we always emit it when priv->master changes). If we would fix that to only emit the signal when nm_device_get_master() actually changes, it would still be correct, because device_master_changed() doesn't care about notifications when the master is unset. Hence, the only user doesn't care about the difference. So change it because it's unexpected that the property and function are not completely equal.
2015-08-06 13:23:56 +02:00
g_value_set_object (value, nm_device_get_master (self));
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
case PROP_PARENT:
nm_utils_g_value_set_object_path (value, priv->parent_device);
break;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
case PROP_HW_ADDRESS:
core: update data types of some hwaddr properties Now that we have nm_utils_hwaddr_matches() for comparing addresses (even when one is a string and the other binary), there are now places where it's more convenient to store hardware addresses as strings rather than binary, since we want them in string form for most non-comparison purposes. So update for that. In particular, this also changes nm_device_get_hw_address() to return a string. Also, simplify the update_permanent_hw_address() implementations by assuming that they will only be called once. (Since they will.)
2014-06-21 12:44:56 -04:00
g_value_set_string (value, priv->hw_addr);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
break;
device: treat fake permanent MAC address mostly like a real one Now that we persist the fake permanent address across restart of NetworkManager, we want to consider fake addresses as good enough in most cases.
2016-10-13 18:52:12 +02:00
case PROP_PERM_HW_ADDRESS: {
const char *perm_hw_addr;
gboolean perm_hw_addr_is_fake;
device: delay capturing permanent MAC address until UDEV is settled The permanent MAC address of an NMDevice shall not change as long as the device is realized. That is, we read it only once and don't change it afterwards. There are two issues that this commit tries to mitigate: (1) users are advised to use UDEV to rename interfaces. As we lookup the permenent MAC address using ethtool (which uses the interface name), there is a race where we could read the permanent MAC address using the wrong interface name. We should wait until UDEV finished initializing the device and until the interface name is stable (see rh#1388286). This commit still cannot avoid the race of ethtool entirely. It only tries to avoid ethtool until UDEV has done its work. That is, until we expect the interface name no longer to change. (2) some device types, don't have a permanent MAC address so we fall back to use the currently set address (fake). Again, users are advised to use UDEV to configure the MAC addresses on such software devices. Thus, we should not get the fake MAC address until UDEV initialized the device. This patch actually doesn't solve the problem at all yet. The reason is that a regular caller of nm_device_get_permanent_hw_address() can not afford to wait until UDEV settled. Thus, any user who requests the permanent MAC address before the link is initialized, runs into the problems above. In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address() and delay them until the link is initialized.
2016-10-24 12:50:17 +02:00
perm_hw_addr = nm_device_get_permanent_hw_address_full (self, FALSE, &perm_hw_addr_is_fake);
device: implememnt "perm-hw-address" property in NMDevice Both NMDeviceEthernet and NMDeviceWifi have a property "perm-hw-address". As the hw_addr_perm property is tracked in the parent NMDevice class, let it also implement the GObject property. Then it knows better when to emit a notification about property changes.
2016-06-17 18:53:45 +02:00
/* this property is exposed on D-Bus for NMDeviceEthernet and NMDeviceWifi. */
device: treat fake permanent MAC address mostly like a real one Now that we persist the fake permanent address across restart of NetworkManager, we want to consider fake addresses as good enough in most cases.
2016-10-13 18:52:12 +02:00
g_value_set_string (value, perm_hw_addr && !perm_hw_addr_is_fake ? perm_hw_addr : NULL);
device: implememnt "perm-hw-address" property in NMDevice Both NMDeviceEthernet and NMDeviceWifi have a property "perm-hw-address". As the hw_addr_perm property is tracked in the parent NMDevice class, let it also implement the GObject property. Then it knows better when to emit a notification about property changes.
2016-06-17 18:53:45 +02:00
break;
device: treat fake permanent MAC address mostly like a real one Now that we persist the fake permanent address across restart of NetworkManager, we want to consider fake addresses as good enough in most cases.
2016-10-13 18:52:12 +02:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
case PROP_HAS_PENDING_ACTION:
g_value_set_boolean (value, nm_device_has_pending_action (self));
break;
core,libnm: add 'metered' property to NMDevice
2015-04-29 16:34:38 +02:00
case PROP_METERED:
g_value_set_uint (value, priv->metered);
break;
device: export list of LLDP neighbors through D-Bus This adds a LldpNeighbors property to the Device D-Bus interface carrying information about devices discovered through LLDP. The property is an array of hashes and each hash describes the values of LLDP TLVs for a specific neighbor.
2015-10-07 11:48:38 +02:00
case PROP_LLDP_NEIGHBORS:
if (priv->lldp_listener)
g_value_set_variant (value, nm_lldp_listener_get_neighbors (priv->lldp_listener));
else {
g_variant_builder_init (&array_builder, G_VARIANT_TYPE ("aa{sv}"));
g_value_take_variant (value, g_variant_builder_end (&array_builder));
}
break;
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
case PROP_REAL:
device: only set NMDevice as "real" at the end of nm_device_realize_finish() Only set the device as "real" at the end of nm_device_realize_finish(), not already during nm_device_realize_start()/realize_start_setup().
2016-01-12 10:38:16 +01:00
g_value_set_boolean (value, nm_device_is_real (self));
core: add "real" NMDevice property This property is TRUE for devices that exist either as a kernel device or are backed by some other resource (eg, ModemManager object, Bluez device, etc). It will eventually be FALSE for software devices that are not yet instantiated.
2014-09-05 08:50:02 -05:00
break;
device: implement slave property in parent device class Instead of reimplementing the slave property in bond, bridge and team, just add the property to the parent class. It's not that the parent class would be agnostic to the master/slave implementation, all the slaves are known to the every device type implementation. Also, the derived class doesn't know the correct time when to invoke the notify-changed for the slaves property. E.g. it should be only invoked after nm_device_slave_notify_enslave() when other components also consider the slave as enslaved. Later this will be fixed so that the SLAVES property correspond to what other master/slave related properties say.
2015-12-02 10:33:19 +01:00
case PROP_SLAVES: {
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
CList *slave_iter;
device: implement slave property in parent device class Instead of reimplementing the slave property in bond, bridge and team, just add the property to the parent class. It's not that the parent class would be agnostic to the master/slave implementation, all the slaves are known to the every device type implementation. Also, the derived class doesn't know the correct time when to invoke the notify-changed for the slaves property. E.g. it should be only invoked after nm_device_slave_notify_enslave() when other components also consider the slave as enslaved. Later this will be fixed so that the SLAVES property correspond to what other master/slave related properties say.
2015-12-02 10:33:19 +01:00
char **slave_list;
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
gsize i, n;
device: implement slave property in parent device class Instead of reimplementing the slave property in bond, bridge and team, just add the property to the parent class. It's not that the parent class would be agnostic to the master/slave implementation, all the slaves are known to the every device type implementation. Also, the derived class doesn't know the correct time when to invoke the notify-changed for the slaves property. E.g. it should be only invoked after nm_device_slave_notify_enslave() when other components also consider the slave as enslaved. Later this will be fixed so that the SLAVES property correspond to what other master/slave related properties say.
2015-12-02 10:33:19 +01:00
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
n = c_list_length (&priv->slaves);
slave_list = g_new (char *, n + 1);
i = 0;
c_list_for_each (slave_iter, &priv->slaves) {
SlaveInfo *info = c_list_entry (slave_iter, SlaveInfo, lst_slave);
device: implement slave property in parent device class Instead of reimplementing the slave property in bond, bridge and team, just add the property to the parent class. It's not that the parent class would be agnostic to the master/slave implementation, all the slaves are known to the every device type implementation. Also, the derived class doesn't know the correct time when to invoke the notify-changed for the slaves property. E.g. it should be only invoked after nm_device_slave_notify_enslave() when other components also consider the slave as enslaved. Later this will be fixed so that the SLAVES property correspond to what other master/slave related properties say.
2015-12-02 10:33:19 +01:00
const char *path;
device: cleanup handling master/slave relationships in NMDevice I found the handling of the master-device very confusing because it was unclear who sets priv->master, and when it should be set. Now: - Setting priv->master (in a slave) always goes together with adding the master to priv->slaves (in the master). Previously, this was done at separate places, so it was not clear if master and slave always agree on their relationship -- in fact, they did not. - There are now three basic functions which do the enslaving/releasing: (1) nm_device_master_add_slave() (2) nm_device_master_enslave_slave() (3) nm_device_master_release_one_slave() Step 3/release basically undoes the 1/add and 2/enslave steps. - completing the enslaving/releasing is now done by (1) nm_device_slave_notify_enslave() (2) nm_device_slave_notify_release() These functions also emit signals like NM_DEVICE_MASTER. - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead the notification is emited together with NM_DEVICE_MASTER, whenever a slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes slaves that are actually @is_enslaved.
2015-12-02 10:53:16 +01:00
if (!NM_DEVICE_GET_PRIVATE (info->slave)->is_enslaved)
continue;
device: implement slave property in parent device class Instead of reimplementing the slave property in bond, bridge and team, just add the property to the parent class. It's not that the parent class would be agnostic to the master/slave implementation, all the slaves are known to the every device type implementation. Also, the derived class doesn't know the correct time when to invoke the notify-changed for the slaves property. E.g. it should be only invoked after nm_device_slave_notify_enslave() when other components also consider the slave as enslaved. Later this will be fixed so that the SLAVES property correspond to what other master/slave related properties say.
2015-12-02 10:33:19 +01:00
path = nm_exported_object_get_path ((NMExportedObject *) info->slave);
if (path)
slave_list[i++] = g_strdup (path);
}
device: use CList to track SlaveInfo
2017-05-13 21:57:51 +02:00
nm_assert (i <= n);
device: implement slave property in parent device class Instead of reimplementing the slave property in bond, bridge and team, just add the property to the parent class. It's not that the parent class would be agnostic to the master/slave implementation, all the slaves are known to the every device type implementation. Also, the derived class doesn't know the correct time when to invoke the notify-changed for the slaves property. E.g. it should be only invoked after nm_device_slave_notify_enslave() when other components also consider the slave as enslaved. Later this will be fixed so that the SLAVES property correspond to what other master/slave related properties say.
2015-12-02 10:33:19 +01:00
slave_list[i] = NULL;
g_value_take_boxed (value, slave_list);
break;
}
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
case PROP_REFRESH_RATE_MS:
device: namespace fields related to statistics in NMDevicePrivate ... by grouping them together in a struct.
2016-08-16 11:35:23 +02:00
g_value_set_uint (value, priv->stats.refresh_rate_ms);
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
break;
case PROP_TX_BYTES:
device: namespace fields related to statistics in NMDevicePrivate ... by grouping them together in a struct.
2016-08-16 11:35:23 +02:00
g_value_set_uint64 (value, priv->stats.tx_bytes);
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
break;
case PROP_RX_BYTES:
device: namespace fields related to statistics in NMDevicePrivate ... by grouping them together in a struct.
2016-08-16 11:35:23 +02:00
g_value_set_uint64 (value, priv->stats.rx_bytes);
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
break;
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
case PROP_CONNECTIVITY:
g_value_set_uint (value, priv->connectivity_state);
break;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
}
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
static void
nm_device_class_init (NMDeviceClass *klass)
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
{
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
GObjectClass *object_class = G_OBJECT_CLASS (klass);
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
NMExportedObjectClass *exported_object_class = NM_EXPORTED_OBJECT_CLASS (klass);
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
g_type_class_add_private (object_class, sizeof (NMDevicePrivate));
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
exported-object: use NM_EXPORT_PATH_NUMBERED() macro
2017-01-03 15:27:23 +01:00
exported_object_class->export_path = NM_EXPORT_PATH_NUMBERED (NM_DBUS_PATH"/Devices");
core: move D-Bus export/unexport into NMExportedObject Move D-Bus export/unexport handling into NMExportedObject and remove type-specific export/get_path methods (export paths are now specified at the class level, and NMExportedObject handles the counters for all exported types automatically). Since all exportable objects now use the same get_path() method, we can also add some helper methods to simplify get_property() implementations for object-path and object-path-array properties.
2015-04-03 10:08:52 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
object_class->dispose = dispose;
object_class->finalize = finalize;
object_class->set_property = set_property;
object_class->get_property = get_property;
device: move initialization of ifindex to constructor() Device subclasses (for example NMDeviceWifi) can use the ifindex in their constructor(), but the value now is set later in parent class constructed(). This causes the following: nm_platform_wifi_get_capabilities: assertion 'ifindex > 0' failed Fix this by initializing ifindex earlier in NMDevice's constructor(). While at it, remove the nm_assert (pllink->type != NM_LINK_TYPE_NONE); assertion, since pllink can be NULL there. Fixes: 6db04dc20664479fc71f102a536dbf2f4501c5a2
2015-12-09 10:29:15 +01:00
object_class->constructor = constructor;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
object_class->constructed = constructed;
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
klass->link_changed = link_changed;
core: add AvailableConnections property for NMDevice objects Implements a new property that provides a list of currently available connections a device could connect to. For example if a connection for a particular wireless connection exists and that wireless network appears in the scan list it would show in the AvailableConnections property of the device. (dcbw: found a slightly cleaner way to do this; it's a lot like the check_connection_compatible class method, except it deals with live network data too. So convert the subclass methods to just check additional live network data, and have the base device class handle adding the connection to the hash and all the associated signalling. Also fix a bug where the available connections were not updated when a device moved from UNAVAILABLE to available, its available connections were not updated)
2012-08-01 11:16:48 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
klass->is_available = is_available;
klass->act_stage1_prepare = act_stage1_prepare;
klass->act_stage2_config = act_stage2_config;
klass->act_stage3_ip4_config_start = act_stage3_ip4_config_start;
klass->act_stage3_ip6_config_start = act_stage3_ip6_config_start;
klass->act_stage4_ip4_config_timeout = act_stage4_ip4_config_timeout;
klass->act_stage4_ip6_config_timeout = act_stage4_ip6_config_timeout;
core: also check specific object when determining available connections
2013-09-03 15:34:56 -05:00
device: add nm_device_get_type_description() function Add a function to get a concise representation of the device type. libnm already has nm_device_get_type_description() for that and it is shown by nmcli -f GENERAL.TYPE device show Reimplement that function for nm-core. Just take care that the two implementations don't diverge.
2015-05-15 15:00:07 +02:00
klass->get_type_description = get_type_description;
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
klass->can_auto_connect = can_auto_connect;
klass->check_connection_compatible = check_connection_compatible;
klass->check_connection_available = check_connection_available;
device: move the decision whether to wait for IFF_UP a virtual function We'd like to override it for veths.
2015-04-07 14:24:12 +02:00
klass->can_unmanaged_external_down = can_unmanaged_external_down;
device: move implementation of NMDevice:setup_start() to realize_start_setup() All implementations of NMDevice:setup_start() in derived classes invoke the parent implementation first. Enforce that by moving NMDevice:setup_start() to realize_start_setup() and only notify derived classes afterwards via NMDevice:realize_start_notify().
2016-01-08 17:24:24 +01:00
klass->realize_start_notify = realize_start_notify;
device/trivial: rename virtual function NMDevice:unrealize() to unrealize_notify()
2016-01-10 15:18:31 +01:00
klass->unrealize_notify = unrealize_notify;
device: don't call virtual function carrier_changed() directly Don't give the subclass the ability to override the parents behavior. The parent implementation is not intended to allow for that. Instead, restrict the flexibility of how the virtual function integrates with the larger picture. That means, the virtual function is only called at one place, and there is only one implementation in NMDeviceEthernet (and it doesn't really matter whether the implementation chains up the parent implementation or not).
2017-05-12 16:17:18 +02:00
klass->carrier_changed_notify = carrier_changed_notify;
core: use Interface Identifiers for IPv6 SLAAC addresses Ethernet-like interfaces aren't the only type of interfaces that can run IPv6 but the rdisc code only returns an address if the interface's hardware address is 6 bytes. Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own specifications for constructing IPv6 addresses and we should honor those. So instead of expecting a MAC address, let each device subclass generate an Interface Identifier and use that for rdisc instead.
2014-04-10 15:29:45 -05:00
klass->get_ip_iface_identifier = get_ip_iface_identifier;
core: refactor unmanaging devices on shutdown and unmanage Wi-Fi devices Add new virtual function nm_device_unmanage_on_quit() to determine whether to unmanage the device on shutdown. This allows Wi-Fi devices to always be unmanaged. We want that to reset the initial MAC address.
2016-06-21 11:04:38 +02:00
klass->unmanaged_on_quit = unmanaged_on_quit;
device/wifi: properly reset the initial hardware address on shutdown During shutdown, we unmanage Wi-Fi devices, and during NMDevice:deactivate() we would reset to initial MAC address. However, NMDeviceWifi:deactivate() would reset it again to the scanning one. Fix that to properly restore the initial MAC address on the device when NetworkManager exits. Fixes: 4b2e375b3393ca4ebb1069279e919cd5fc9fd2ee
2016-06-30 11:42:28 +02:00
klass->deactivate_reset_hw_addr = deactivate_reset_hw_addr;
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
klass->parent_changed_notify = parent_changed_notify;
device: introduce class methods for connection reapply Add two new methods can_reapply_change() and reapply_connection() to the device class. In this way device subclasses can declare that they support the changes in a given setting and take care of reapplying it.
2017-03-03 12:06:58 +01:00
klass->can_reapply_change = can_reapply_change;
klass->reapply_connection = reapply_connection;
core: also check specific object when determining available connections
2013-09-03 15:34:56 -05:00
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_UDI] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_UDI, "", "",
NULL,
device: make UDI property construct-only
2017-05-17 15:01:10 +02:00
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_IFACE] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_IFACE, "", "",
NULL,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_IP_IFACE] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_IP_IFACE, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_DRIVER] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_DRIVER, "", "",
NULL,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_DRIVER_VERSION] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_DRIVER_VERSION, "", "",
NULL,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_FIRMWARE_VERSION] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_FIRMWARE_VERSION, "", "",
NULL,
device: fix compile error due to typo Fixes: 6d409653b1bc9116bfb58b074f0c61407aef1038
2016-02-29 13:37:15 +01:00
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_CAPABILITIES] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_uint (NM_DEVICE_CAPABILITIES, "", "",
0, G_MAXUINT32, NM_DEVICE_CAP_NONE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_CARRIER] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boolean (NM_DEVICE_CARRIER, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_MTU] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_uint (NM_DEVICE_MTU, "", "",
0, G_MAXUINT32, 1500,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_IP4_ADDRESS] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_uint (NM_DEVICE_IP4_ADDRESS, "", "",
0, G_MAXUINT32, 0, /* FIXME */
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_IP4_CONFIG] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_IP4_CONFIG, "", "",
NULL,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_DHCP4_CONFIG] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_DHCP4_CONFIG, "", "",
NULL,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_IP6_CONFIG] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_IP6_CONFIG, "", "",
NULL,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_DHCP6_CONFIG] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_DHCP6_CONFIG, "", "",
NULL,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_STATE] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_uint (NM_DEVICE_STATE, "", "",
0, G_MAXUINT32, NM_DEVICE_STATE_UNKNOWN,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_STATE_REASON] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_variant (NM_DEVICE_STATE_REASON, "", "",
G_VARIANT_TYPE ("(uu)"),
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_ACTIVE_CONNECTION] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_ACTIVE_CONNECTION, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_DEVICE_TYPE] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_uint (NM_DEVICE_DEVICE_TYPE, "", "",
0, G_MAXUINT32, NM_DEVICE_TYPE_UNKNOWN,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_LINK_TYPE] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_uint (NM_DEVICE_LINK_TYPE, "", "",
0, G_MAXUINT32, NM_LINK_TYPE_NONE,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_MANAGED] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boolean (NM_DEVICE_MANAGED, "", "",
FALSE,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_AUTOCONNECT] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boolean (NM_DEVICE_AUTOCONNECT, "", "",
DEFAULT_AUTOCONNECT,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_FIRMWARE_MISSING] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boolean (NM_DEVICE_FIRMWARE_MISSING, "", "",
FALSE,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_NM_PLUGIN_MISSING] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boolean (NM_DEVICE_NM_PLUGIN_MISSING, "", "",
FALSE,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_TYPE_DESC] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_TYPE_DESC, "", "",
NULL,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_RFKILL_TYPE] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_uint (NM_DEVICE_RFKILL_TYPE, "", "",
RFKILL_TYPE_WLAN,
RFKILL_TYPE_MAX,
RFKILL_TYPE_UNKNOWN,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_IFINDEX] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_int (NM_DEVICE_IFINDEX, "", "",
0, G_MAXINT, 0,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_AVAILABLE_CONNECTIONS] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boxed (NM_DEVICE_AVAILABLE_CONNECTIONS, "", "",
G_TYPE_STRV,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_PHYSICAL_PORT_ID] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_PHYSICAL_PORT_ID, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_MASTER] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_object (NM_DEVICE_MASTER, "", "",
NM_TYPE_DEVICE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: track parent device in NMDevice Multiple subclasses have a parent/link interface (NMDeviceIPTunnel, NMDeviceVlan). Tracking the parent interface properly is midly complicated to get right. So, instead of repeating it in each subclass, track it in the parent device.
2016-12-26 11:12:39 +01:00
obj_properties[PROP_PARENT] =
g_param_spec_string (NM_DEVICE_PARENT, "", "",
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_HW_ADDRESS] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_string (NM_DEVICE_HW_ADDRESS, "", "",
NULL,
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
G_PARAM_READABLE |
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
G_PARAM_STATIC_STRINGS);
device: implememnt "perm-hw-address" property in NMDevice Both NMDeviceEthernet and NMDeviceWifi have a property "perm-hw-address". As the hw_addr_perm property is tracked in the parent NMDevice class, let it also implement the GObject property. Then it knows better when to emit a notification about property changes.
2016-06-17 18:53:45 +02:00
obj_properties[PROP_PERM_HW_ADDRESS] =
g_param_spec_string (NM_DEVICE_PERM_HW_ADDRESS, "", "",
NULL,
device: let device specs match on permanent MAC address Using the current, possibly non-permanent MAC address doesn't really make sense. Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt to the bdaddr. That is wrong, because bdaddr should not be the current address, but the permanent one.
2016-06-15 11:25:29 +02:00
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY |
device: implememnt "perm-hw-address" property in NMDevice Both NMDeviceEthernet and NMDeviceWifi have a property "perm-hw-address". As the hw_addr_perm property is tracked in the parent NMDevice class, let it also implement the GObject property. Then it knows better when to emit a notification about property changes.
2016-06-17 18:53:45 +02:00
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_HAS_PENDING_ACTION] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boolean (NM_DEVICE_HAS_PENDING_ACTION, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
core: add parameter to ignore error in add/remove pending action Add a parameter to nm_device_add_pending_action() to silently accept adding duplicate actions. Same for nm_device_remove_pending_action(), to silently ignore removing non-pending actions. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-04-28 11:18:05 +02:00
core,libnm: add 'metered' property to NMDevice
2015-04-29 16:34:38 +02:00
/**
* NMDevice:metered:
*
* Whether the connection is metered.
*
* Since: 1.2
**/
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_METERED] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_uint (NM_DEVICE_METERED, "", "",
0, G_MAXUINT32, NM_METERED_UNKNOWN,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_LLDP_NEIGHBORS] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_variant (NM_DEVICE_LLDP_NEIGHBORS, "", "",
G_VARIANT_TYPE ("aa{sv}"),
NULL,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_REAL] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boolean (NM_DEVICE_REAL, "", "",
FALSE,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
obj_properties[PROP_SLAVES] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_param_spec_boxed (NM_DEVICE_SLAVES, "", "",
G_TYPE_STRV,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
/* Statistics */
obj_properties[PROP_REFRESH_RATE_MS] =
g_param_spec_uint (NM_DEVICE_STATISTICS_REFRESH_RATE_MS, "", "",
0, UINT32_MAX, 0,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_TX_BYTES] =
g_param_spec_uint64 (NM_DEVICE_STATISTICS_TX_BYTES, "", "",
0, UINT64_MAX, 0,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
obj_properties[PROP_RX_BYTES] =
g_param_spec_uint64 (NM_DEVICE_STATISTICS_RX_BYTES, "", "",
0, UINT64_MAX, 0,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
/* Connectivity */
obj_properties[PROP_CONNECTIVITY] =
g_param_spec_uint (NM_DEVICE_CONNECTIVITY, "", "",
NM_CONNECTIVITY_UNKNOWN, NM_CONNECTIVITY_FULL, NM_CONNECTIVITY_UNKNOWN,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
device: use _notify() instead of g_object_notify() for object properties https://github.com/NetworkManager/NetworkManager/pull/3
2016-02-29 16:27:27 +05:30
g_object_class_install_properties (object_class, _PROPERTY_ENUMS_LAST, obj_properties);
device: implement slave property in parent device class Instead of reimplementing the slave property in bond, bridge and team, just add the property to the parent class. It's not that the parent class would be agnostic to the master/slave implementation, all the slaves are known to the every device type implementation. Also, the derived class doesn't know the correct time when to invoke the notify-changed for the slaves property. E.g. it should be only invoked after nm_device_slave_notify_enslave() when other components also consider the slave as enslaved. Later this will be fixed so that the SLAVES property correspond to what other master/slave related properties say.
2015-12-02 10:33:19 +01:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
signals[STATE_CHANGED] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_signal_new (NM_DEVICE_STATE_CHANGED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_LAST,
G_STRUCT_OFFSET (NMDeviceClass, state_changed),
NULL, NULL, NULL,
G_TYPE_NONE, 3,
G_TYPE_UINT, G_TYPE_UINT, G_TYPE_UINT);
core: add NMManager:startup property 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.
2013-08-13 17:45:34 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
signals[AUTOCONNECT_ALLOWED] =
core: use defines for signal names
2016-09-12 12:29:34 +02:00
g_signal_new (NM_DEVICE_AUTOCONNECT_ALLOWED,
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_LAST,
0,
autoconnect_allowed_accumulator, NULL, NULL,
G_TYPE_BOOLEAN, 0);
core: add NMManager:startup property 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.
2013-08-13 17:45:34 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
signals[AUTH_REQUEST] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_signal_new (NM_DEVICE_AUTH_REQUEST,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
/* context, connection, permission, allow_interaction, callback, user_data */
G_TYPE_NONE, 6, G_TYPE_DBUS_METHOD_INVOCATION, NM_TYPE_CONNECTION, G_TYPE_STRING, G_TYPE_BOOLEAN, G_TYPE_POINTER, G_TYPE_POINTER);
core: add NMManager:startup property 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.
2013-08-13 17:45:34 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
signals[IP4_CONFIG_CHANGED] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_signal_new (NM_DEVICE_IP4_CONFIG_CHANGED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 2, G_TYPE_OBJECT, G_TYPE_OBJECT);
core: convert pending actions from a counter to a GArray This lets us do two things: 1) ensure that pending actions are unique and not doubly added/removed 2) we can (eventually) print out the pending action list for debugging However, since we cannot have two pending actions with the same name at the same time, we need to change the queued device state actions to include the state name. But that makes debugging even more descriptive so it's a bonus.
2013-12-09 12:55:04 -06:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
signals[IP6_CONFIG_CHANGED] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_signal_new (NM_DEVICE_IP6_CONFIG_CHANGED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 2, G_TYPE_OBJECT, G_TYPE_OBJECT);
core: add NMManager:startup property 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.
2013-08-13 17:45:34 -04:00
device: add IPv6 configuration delegation machinery There's two parts of the configuration involved: the subnet addresses and the DNS information. For the addressing, the shared (downlink) device signals the policy needs for a /64 subnet. When it gets one, it merges it into the autoconf configuration and forwards to the NDisc. When more prefixes are needed, the (uplink) device asks the DHCP manager and eventually signals delegation (reception) of a prefix. The NMDevice only provides the mechanism, the actual subnetting needs to be done by the NMPolicy. For the DNS configuration, the shared device just copies it from whichever device the policy deems suitable.
2016-11-03 12:05:12 +01:00
signals[IP6_PREFIX_DELEGATED] =
g_signal_new (NM_DEVICE_IP6_PREFIX_DELEGATED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 1, G_TYPE_POINTER);
signals[IP6_SUBNET_NEEDED] =
g_signal_new (NM_DEVICE_IP6_SUBNET_NEEDED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 0);
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
signals[REMOVED] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_signal_new (NM_DEVICE_REMOVED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 0);
core: add NMManager:startup property 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.
2013-08-13 17:45:34 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
signals[RECHECK_AUTO_ACTIVATE] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_signal_new (NM_DEVICE_RECHECK_AUTO_ACTIVATE,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 0);
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
core: re-order NMDevice functions to match current idoms Move the GObject-related stuff to the bottom of the file and get rid of no-longer-necessary forward prototypes since the stuff that required those prototypes is now below the implementation.
2014-05-20 15:03:27 -05:00
signals[RECHECK_ASSUME] =
device/trivial: adjust whitespace for property definitions
2016-02-29 13:13:54 +01:00
g_signal_new (NM_DEVICE_RECHECK_ASSUME,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 0);
core: improve handling of NPAR/SR-IOV devices (rh #804527) Use the new kernel physical_port_id interface property to recognize when two devices are just virtual devices sharing the same physical port, and refuse to bond/team multiple slaves on the same port.
2013-10-11 14:59:26 -04:00
core: add an NMExportedObject base class Add NMExportedObject, make it the base class of all D-Bus-exported types, and move the nm-properties-changed-signal logic into it. (Also, make NMSettings use the same properties-changed code as everything else, which it was not previously doing, presumably for historical reasons). (This is mostly just shuffling code around at this point, but NMExportedObject will be more important in the gdbus port, since gdbus-codegen doesn't do a very good job of supporting objects that export multiple interfaces [as each NMDevice subclass does, for example], so we will need more glue/helper code in NMExportedObject then.)
2015-04-13 13:31:42 -04:00
nm_exported_object_class_add_interface (NM_EXPORTED_OBJECT_CLASS (klass),
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
NMDBUS_TYPE_DEVICE_SKELETON,
device: add O.FD.NM.Device.Reapply() call The introspection data and daemon stub. There's no settings that can be reapplied at the moment.
2015-11-02 15:32:38 +01:00
"Reapply", impl_device_reapply,
core: add NMDevice's GetAppliedConnection D-Bus call Expose applied connection in D-Bus API. https://bugzilla.gnome.org/show_bug.cgi?id=760884
2016-02-11 09:18:35 +01:00
"GetAppliedConnection", impl_device_get_applied_connection,
devices, active-connection: port to gdbus
2015-04-15 14:53:30 -04:00
"Disconnect", impl_device_disconnect,
"Delete", impl_device_delete,
NULL);
device: add statistics interface Add statistics interface to all device instances. When active, the properties of this interface are refreshed whenever there is network activity for the device. Activation is performed by changing RefreshRateMs property. If set to zero, the interface is deactivated. If set to other value, the rest of the interface properties are refreshed whenever the related network metric changes, being RefreshRateMs the minimum time between property changes, in milliseconds.
2016-08-10 11:54:31 +02:00
nm_exported_object_class_add_interface (NM_EXPORTED_OBJECT_CLASS (klass),
NMDBUS_TYPE_DEVICE_STATISTICS_SKELETON,
NULL);
device: add 'mtu' property
2013-12-16 15:16:43 +01:00
}
Reference in a new issue Copy permalink