summaryrefslogtreecommitdiff
path: root/src/nm-manager.c
Commit message (Collapse)AuthorAgeFilesLines
* manager: add a method to get a particular device of given typeLubomir Rintel2017-10-301-7/+23
| | | | And also make the remove_device() method use it behind the scenes.
* manager: always update the device when the plink comes and goesLubomir Rintel2017-10-301-0/+3
| | | | | | | | | | | 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.
* manager: don't assign a new link to a device of a different link typeLubomir Rintel2017-10-301-0/+3
|
* manager: match device type when removing an ip interfaceLubomir Rintel2017-10-301-0/+2
| | | | Otherwise we might end up removing a wrong device of a same name.
* settings: extend commit_changes() to update the settings after writingThomas Haller2017-10-251-0/+1
| | | | | | | | | | | | | | | | | | | During write, it can regularly happen that the connection gets modified. For example, keyfile never writes blobs as-is, it always writes the blob to an external file, and replaces the certificate property with a path. Other reasons could be just bugs, where the reader and writer are not doing a proper round trip (these cases should be fixed). Refactor commit_changes(), to return the re-read connection to the settings-connection class, and handle replacing the settings there. Also, prepare for another change. Sometimes we first call replace_settings() followed by commit_changes(). It would be better to instead call commit_changes() first, and only on success proceed with replace_settings(). Hence, commit_changes() gets a new argument new_connection, that can be used to write another connection to disk.
* settings: get rid of callback arguments for nm_settings_connection_delete()Thomas Haller2017-10-251-3/+3
|
* settings: get rid of callback arguments for ↵Thomas Haller2017-10-251-1/+1
| | | | | | | nm_settings_connection_commit_changes() No need to return an error result via a callback function. Just return the plain error.
* manager: fix evaluation of manager stateBeniamino Galvani2017-10-201-1/+1
| | | | | | | | | The state should be set to CONNECTED_GLOBAL only when there is full connectivity. Fixes: 9d43869e473b47542520c807dace93a6f9520964 https://bugzilla.gnome.org/show_bug.cgi?id=785281
* device/trivial: rename nm_device_get_ip_route_metric() to ↵Thomas Haller2017-10-061-4/+4
| | | | | | nm_device_get_route_metric() Brevity!
* device: remove wrappers for nm_device_get_ip_route_metric()Thomas Haller2017-10-061-4/+4
|
* core: avoid compiler warnings related to cleanup attributeThomas Haller2017-10-051-1/+2
| | | | | | | | | gcc doesn't consider variables with cleanup attribute as unused. clang does, and warns about them. In one case, clang is right, in the other one the warning is bogus. Fix both.
* core: keep platform link object alive and don't copy itThomas Haller2017-09-291-6/+5
| | | | | | | | | | | | | | | 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.
* manager: refactor lifetime handling for idle callback _platform_link_cb_idle()Thomas Haller2017-09-291-15/+29
| | | | | | | | | | | | We call _platform_link_cb_idle() on idle, so we must take care of the lifetime of NMManager. We don't want to take a reference, so that the manager is not kept alive by platform events. Refactor the previous implementation with weak pointers to use a linked list instead. Let's not have any pending idle actions after the manager instance is destroyed. Instead, properly track and cancel the events.
* manager: disconnect platform_link_cb() from NMManager in dispose()Thomas Haller2017-09-291-0/+4
|
* manager/trivial: rename self variable in NMManager:dispose()Thomas Haller2017-09-291-19/+19
|
* manager: don't use platform singleton but keep a private pointerThomas Haller2017-09-291-12/+23
| | | | | | | | | | We should reduce uses of singletons in general. Instead, the platform instance should be passed around and kept for as long as it's needed. Especially, as we subscribe platform_link_cb() signal. Currently, we never unsubscribe it (wrongly). Subscribing signals is a strong indication that the target object should keep the source object alive until the signal is unsubscribed.
* manager: ignore unmanaged devices when looking for parent by UUIDBeniamino Galvani2017-09-281-0/+4
| | | | | | If the device is unmanaged, it is not compatible with any connection. https://mail.gnome.org/archives/networkmanager-list/2017-September/msg00032.html
* manager: downgrade error message for missing dependenciesBeniamino Galvani2017-09-201-2/+9
| | | | | | | | | | | | | At startup the manager tries to create virtual devices without a specific order and spits warnings when a device can't be realized because the parent device is not yet created. These failures are not something the user should worry about because the creation will be retried when the parent appears. A better approach is to return an error code from the device's create_and_realize() telling that it failed because the parent doesn't exist. In this way, the manager knows that the device isn't ready and can avoid printing warning messages.
* manager: try other connections only after the device is realizedBeniamino Galvani2017-09-201-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a device is created in system_create_virtual_device(), the manager tries to activate connections that depend on the device even if the device isn't realized, as in the following log: # team0 gets created <info> manager: (team0): new Team device (/org/freedesktop/NetworkManager/Devices/7) # team0.23 gets created <debug> device[0x28079b0] (team0.23): constructed (NMDeviceVlan) <debug> manager: (team0-vlan23) create virtual device team0.23 <debug> device[0x28079b0] (team0.23): unmanaged: flags set to [platform-init,!sleeping=0x10/0x11/unmanaged/unrealized], set-managed [sleeping <info> manager: (team0.23): new VLAN device (/org/freedesktop/NetworkManager/Devices/8) # the manager tries to realize team0.23 <debug> device[0x28079b0] (team0.23): create (is nm-owned) <warn> manager: (team0-vlan23) couldn't create the device: cannot retrieve ifindex of interface team0 (Team): skip VLAN creation for now <debug> manager: (team0.23): removing device (allow_unmanage 1, managed 0) <debug> device[0x28079b0] (team0.23): ip4-config: update (commit=0, new-config=(nil)) <debug> device[0x28079b0] (team0.23): ip6-config: update (commit=0, new-config=(nil)) <debug> device[0x28079b0] (team0.23): disposing <debug> device[0x28079b0] (team0.23): ip4-config: update (commit=1, new-config=(nil)) <debug> device[0x28079b0] (team0.23): ip6-config: update (commit=1, new-config=(nil)) <debug> device[0x28079b0] (team0.23): finalize(): NMDeviceVlan # the manager realizes team0 <debug> device[0x2800870] (team0): create (is nm-owned) <debug> platform: link: add link 'team0' of type 'team' (196610) Change the order of operations and try the child connection only after the parent has been realized.
* core: don't require manageable device in unmanaged_to_disconnected()Thomas Haller2017-09-041-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | It seems the assert there is too strict. I don't really understand why it fails, but I also don't see why the assert is supposed to hold. Just return in case the device is unmanagable at this point. The activation shall fail later. Traceback from a test build of commit a7aca2ab08abcc5bee02f0f6f9ffe899919f4234: #0 0x00007fdb28ffb643 in g_logv (log_domain=0x7fdb2b584cc9 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff10630200) at gmessages.c:1086 #1 0x00007fdb28ffb7bf in g_log (log_domain=log_domain@entry=0x7fdb2b584cc9 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7fdb29069190 "%s: assertion '%s' failed") at gmessages.c:1119 #2 0x00007fdb28ffb7f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7fdb2b584cc9 "NetworkManager", pretty_function=pretty_function@entry=0x7fdb2b54fee0 <__func__.38922> "unmanaged_to_disconnected", expression=expression@entry=0x7fdb2b54d450 "nm_device_get_managed (device, FALSE)") at gmessages.c:1128 #3 0x00007fdb2b36e05b in unmanaged_to_disconnected (device=device@entry=0x7fdb2d2384f0 [NMDeviceVlan]) at src/nm-manager.c:3201 #4 0x00007fdb2b37eb3a in _internal_activate_generic (error=0x7fff106303d0, active=0x7fdb2d1d4550 [NMActRequest], self=0x0) at src/nm-manager.c:3430 #5 0x00007fdb2b37eb3a in _internal_activate_generic (self=self@entry=0x7fdb2d02b090 [NMManager], active=active@entry=0x7fdb2d1d4550 [NMActRequest], error=error@entry=0x7fff10630450) at src/nm-manager.c:3458 #6 0x00007fdb2b37fe90 in _activation_auth_done (active=0x7fdb2d1d4550 [NMActRequest], success=1, error_desc=0x0, user_data1=0x7fdb2d02b090, user_data2=0x7fdb0800bec0) at src/nm-manager.c:3866 #7 0x00007fdb2b4cc9d7 in auth_done (chain=0x7fdb2d17de30, error=0x0, unused=<optimized out>, user_data=<optimized out>) at src/nm-active-connection.c:929 #8 0x00007fdb2b4d6884 in auth_chain_finish (user_data=0x7fdb2d17de30) at src/nm-auth-utils.c:92 #9 0x00007fdb28ff4d7a in g_main_context_dispatch (context=0x7fdb2cff2e00) at gmain.c:3152 #10 0x00007fdb28ff4d7a in g_main_context_dispatch (context=context@entry=0x7fdb2cff2e00) at gmain.c:3767 #11 0x00007fdb28ff50b8 in g_main_context_iterate (context=0x7fdb2cff2e00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838 #12 0x00007fdb28ff538a in g_main_loop_run (loop=0x7fdb2cff2ec0) at gmain.c:4032 #13 0x00007fdb2b349ed7 in main (argc=1, argv=0x7fff106307a8) at src/main.c:438 https://bugzilla.redhat.com/show_bug.cgi?id=1478911
* manager: add connectivity-check-{available,enabled} properties.James Henstridge2017-08-171-0/+33
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=785117
* core: implement activation of PPP devicesBeniamino Galvani2017-08-051-0/+18
| | | | | | | | | | | | 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.
* platform: refactor NMPObject cast macros using _Generic()th/dedup-multi-bgo784220Thomas Haller2017-07-051-1/+1
| | | | This way, we also accept void pointers, while preserving constness.
* platform: refactor nm_platform_link_get_all() to return GPtrArrayThomas Haller2017-07-051-10/+10
| | | | | Instead of doing a full clone, return a pointer array (with references owned). The NMPlatformLink instances are now immutable.
* manager: when a connection is upped on a device, do an early update of its ↵Francesco Giudici2017-06-211-2/+3
| | | | | | | | | | | | | | internal state When a user forces up a connection on a device, mark earlier the device as managed: this would allow proper clean-up on the device also when it was previously unmanaged or assumed. This would avoid skipping IPv6LL address generation when instead it was needed. Fixes: adbf383628138b4f868456996123c4900537a4fb https://bugzilla.redhat.com/show_bug.cgi?id=1452046
* manager: avoid that auto-activations preempt user activationsBeniamino Galvani2017-06-191-0/+26
| | | | | | | | | | | | | | | | In _internal_activate_device(), we try to find an existing master AC for the slave AC, and we create a new one in case of failure. The master AC may already exist, but it may not be detected by find_master() because it is undergoing authorization. The result is that we auto-activate the master when there is already a user activation in place, and the auto-activation will cancel the user one. This is bad, as user-activation should always have precedence. To fix this, introduce a last-minute check before activating internal connections. https://bugzilla.redhat.com/show_bug.cgi?id=1450219
* device: suppress logging and return error reason from ↵Thomas Haller2017-06-081-2/+4
| | | | | | | | 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.
* manager: cleanup logging message during ↵Thomas Haller2017-06-081-28/+24
| | | | | | | | recheck_assume_connection()/get_existing_connection() recheck_assume_connection() calls get_existing_connection(). We want *one* logging message telling what's happening. Let get_existing_connection() log "assume:" messages and remove duplicate messages from recheck_assume_connection().
* manager: add more logging to recheck_assume_connection()Thomas Haller2017-06-081-4/+9
| | | | and give all lines a logging prefix.
* manager: add "rfkill" prefix to related logging messagesThomas Haller2017-06-081-11/+11
|
* manager: add logging macro _NMLOG3() for logging connection messagesThomas Haller2017-06-081-14/+36
| | | | | It unifies the way how we print the logging prefix, but also it passes the con_uuid down for structured logging.
* manager: add logging macro _NMLOG2() for logging device messagesThomas Haller2017-06-081-44/+53
| | | | | It unifies the way how we print the logging prefix, but also it passes the ifname down for structured logging.
* manager: fix preserving assume state during activationThomas Haller2017-06-081-45/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* core: allow assuming connections on "nm-owned" software devicesThomas Haller2017-06-081-3/+0
| | | | | Especially now we load the nm-owned flag from run-state. We very much want to assume connections on such devices.
* device: only set nm-owned from statefile during initial setupThomas Haller2017-06-081-0/+3
| | | | | | | | | | | | | 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.
* manager: restore the previous persistent nm-owned state of devicesBeniamino Galvani2017-06-071-1/+4
| | | | | | | | | | | 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
* config: allow persisting the device nm-owned stateBeniamino Galvani2017-06-071-1/+2
|
* device: rename priv->is_nm_owned to priv->nm_ownedBeniamino Galvani2017-06-071-1/+1
| | | | | Only a matter of taste, but nm_device_get_is_nm_owned() sounds strange.
* core: minor refactoring condition in validate_activation_request()Thomas Haller2017-06-071-15/+11
|
* device: mark device as sys-iface-state=external when assuming connectionThomas Haller2017-06-051-2/+4
| | | | | | | | | | | | | | Since commit 74dac5f (nm-manager: try assuming connections on managed devices), and commit f4226e7 (manager: avoid generating in memory connections during startup for managed devices), recheck_assume_connection() also assumes connections on devices that are currently not in sys-iface-state "external". That is correct, as also for fully managed devices (which are currently in disconnected state), we want to assume external connections. However, when doing that, we must reset the sys-iface-state to external. https://bugzilla.redhat.com/show_bug.cgi?id=1457242
* device: when setting back a device to managed, update internal sys stateFrancesco Giudici2017-05-261-0/+2
| | | | | | | | 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.
* core: add configuration flag to choose slaves activation orderBeniamino Galvani2017-05-241-6/+20
| | | | | | | | | Commits 39d0559d9a7a ("platform: sort links by name instead of ifindex") and 529a0a1a7f19 ("manager: sort slaves to be autoconnected by device name") changed the order of activation of slaves. Introduce a system-wide configuration property to preserve the old behavior. https://bugzilla.redhat.com/show_bug.cgi?id=1452585
* hostname: cache hostname-manager's hostname propertyThomas Haller2017-05-121-46/+21
| | | | | | | | | | | | | | | | A property preferably only emits a notify-changed signal when the value actually changes and it caches the value (so that between property-changed signals the value is guaranteed not to change). NMSettings and NMManager both already cache the hostname, because NMHostnameManager didn't guarantee this basic concept. Implement it and rely on it from NMSettings and NMPolicy. And remove the copy of the property from NMManager. Move the call for nm_dispatcher_call_hostname() from NMHostnameManager to NMManager. Note that NMPolicy also has a call to the dispatcher when set-transient-hostname returns. This should be cleaned up later.
* hostname: split out hostname management from NMSettingsThomas Haller2017-05-121-1/+4
| | | | | | | | | | | | | Hostname management is complicated. At least, how it is implemented currently. For example, NMPolicy also sets the hostname (NMPolicy calls nm_settings_set_transient_hostname() to have hostnamed set the hostname, but then falls back to sethostname() in settings_set_hostname_cb()). Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and NMPolicy listens to changes from there -- instead of changes from NMSettings. Eventually, NMHostnameManager should contain the hostname parts from NMSettings and NMPolicy.
* manager: avoid generating in memory connections during startup for managed ↵Francesco Giudici2017-05-091-1/+2
| | | | | | | | | | | | | | devices Commit #acf1067a allowed to assume connections on already managed devices. Anyway, in complex scenario with layered connections, during the startup of NetworkManager, this could interfere with the connection assumption based on saved state. So, avoid to re-assume connections on already managed devices during startup. Fixes: acf1067a455b02b60985e209df568d3fcc3fac9e (cherry picked from commit b6b7d909f7023ef1830fe5a072b64e109397f609)
* nm-manager: try assuming connections on managed devicesFrancesco Giudici2017-05-041-1/+5
| | | | | | | | | | | Commit 850c97795 ("device: track system interface state in NMDevice") introduced interface states for devices and prevented checking if a connection should be assumed on already managed devices. This prevented to properly manage the event of an ip configuration added externally to NM to a managed but not (yet) activated device. Fixes: 850c977953e4de3c8bbee64a3d2e8726c971761c (cherry picked from commit acf1067a455b02b60985e209df568d3fcc3fac9e)
* device: fix restricting Generic connection by interface-nameThomas Haller2017-04-261-9/+17
| | | | | | | | | | | | | | | | | NMDeviceGeneric:check_connection_compatible() doesn't check for a matching interface name. It relies on the parent implementation to do that. The parent implementation calls nm_manager_get_connection_iface(). That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has no factory. Maybe this imbalance of having no factory for the Generic device is wrong, but usually factories only match a distinct set of device types, while the generic factory would handle them all (as last resort). Without this, activating a generic connection might activate the wrong interface. (cherry picked from commit 3876b10a4749638c3dcfa7e65b12bfee8030334c)
* device: assume matching connections during first startThomas Haller2017-04-201-24/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly distinguish between two modes when encountering devices with external IP configuration: a) external devices. For those devices we generate a volatile in-memory connection and pretend it's active. However, the device must not be touched by NetworkManager in any way. b) assume, seamless take over. Mostly for restart of NetworkManager, we activate a connection gracefully without going through an down-up cycle. After the device reaches activated state, the device is considered fully managed. For this only an existing, non volatile connection can be used. Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not clearly separated. Since then, we only choose to assume a connection (b) when the state file indicates a matching connection. Now, extend this to also assume connections when: - during first-start (not after a restart) when there is no state file yet. - and, if we have an existing, non volatile, connection which matches the device's configuration. This patch lets NetworkManager assume connection also on first start. That is for example useful when handing over network configuration from initrd. This only applies to existing, permanent, matching(!) connections, so it is a good guess that the user wants NM to take over this interface. This brings us closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'. https://bugzilla.redhat.com/show_bug.cgi?id=1439220 (cherry picked from commit 27b2477cb7dad2410c88c7dfca51f3aad208b881)
* config: remove unused NMConfig self argument from nm_config_device_state_*() APIThomas Haller2017-04-201-7/+3
| | | | | | | | | | | 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. (cherry picked from commit 1940be410cc0272de2f690542f43ef7dcb7bc4e1)
* manager: set interface as removed when the link disappearsBeniamino Galvani2017-04-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | Set the device state as removed when the link disappears, so that in the call to unrealize() when the device is unmanaged we also perform a cleanup of it and especially, we terminate any DHCP client instances running on the device. If we keep DHCP clients running, we can hit assertions later when we start another instance on the same interface, because we kill the old dhclient from the pidfile, and the g_child_watch_add() done by the first client instance is not able to waitpid() it, complaining with: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_child_watch_add()/g_spawn_sync() either directly or indirectly. https://bugzilla.redhat.com/show_bug.cgi?id=1436602 (cherry picked from commit df537d2eac44cffe4512214c87f3f303c5a350d3)
View Lorry Controller Status