summaryrefslogtreecommitdiff
path: root/src/nm-policy.c
Commit message (Collapse)AuthorAgeFilesLines
* core: autoconnect fixes for default-unmanaged devices and property notificationdcbw/unmanaged-availableDan Williams2014-10-231-1/+1
| | | | | | | | | | | | | | | | | 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.
* core: Move NMPlatformSource to nm-types.hLubomir Rintel2014-10-201-12/+12
| | | | | ...and rename it while at it. It's going to be useful outside nm-platform, to weight MTU options from various sources.
* core: prefer connections with higher priority for autoconnectThomas Haller2014-10-121-0/+4
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=580018 Signed-off-by: Thomas Haller <thaller@redhat.com>
* core/policy: refactor auto_activate_device() to use a GPtrArrayThomas Haller2014-10-121-5/+13
| | | | | | | | Next we want to sort the array, g_slist_sort() is not guaranteed to be stable, while g_ptr_array_sort() is. Also, sorting a GSList has worse performance. Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: remove nm_device_get_best_auto_connection()Thomas Haller2014-10-121-10/+10
| | | | | | | | | | | | nm_device_get_best_auto_connection() was only used at one place. It was a very simple function, just iterated over a list finding the first can_auto_connect() connection. At the very least, the name was misleading, because it did not return the 'best', but the 'first' connection. Get rid of the function altogether. Signed-off-by: Thomas Haller <thaller@redhat.com>
* auth: rename file nm-manager-auth.* to nm-auth-utils.*Thomas Haller2014-09-291-1/+1
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm, core, cli, tui: fix the capitalization of various typesDan Winship2014-08-011-18/+18
| | | | | | | | | | | | 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).
* core: fill in nm-types.h, clean out other headersDan Winship2014-07-231-0/+5
| | | | | | | | | | | | | | 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.
* core: use nm_utils_is_specific_hostname() instead of hardcoded "localhost"Jiří Klimeš2014-07-141-4/+1
|
* policy: don't use default hostname as configured hostname (rh #1110436)Jiří Klimeš2014-07-141-1/+2
| | | | | | | | | | | | Even if administrator-configured hostname (/etc/hostname) takes precedence over other hostname configurations, we don't take "localhost", "localhost6", "localhost.localdomain", "localhost6.localdomain6" as such. These values might be set by some tools (like installer). But that's not right and we compensate for that. It doesn't make much sense that an admimistrator would set these values manually (intentionally), because leaving /etc/hostname empty will result in "localhost" hostname anyway (set by systemd). https://bugzilla.redhat.com/show_bug.cgi?id=1110436
* core: use singleton nm_firewall_manager_get() throughout without taking ↵Thomas Haller2014-07-021-12/+7
| | | | | | | | | | | | 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>
* core: don't reject activating devices with incomplete IP configGiovanni Campagna2014-06-301-10/+16
| | | | | | | | | | | | | An activating device may have an IP config that is unrelated to the current activation (for example if it comes from capturing the existing config when NM is started), and that config might not have a gateway, which would have NM ignore that the device is activating until after DHCP. https://bugzilla.gnome.org/show_bug.cgi?id=726400 [thaller@redhat.com: move variables inside if-block] Signed-off-by: Thomas Haller <thaller@redhat.com>
* all: remove remaining GParamSpec name/blurb stringsDan Winship2014-06-191-16/+12
| | | | | | Remove all remaining GParamSpec name and blurb strings (and fix indentation while we're there), and add G_PARAM_STATIC_STRINGS to all paramspecs that were lacking it.
* dispatcher: add synchronous dispatcher callsDan Williams2014-06-061-1/+1
| | | | | | On shutdown we can't defer the response to a callback, so we need to use synchronous D-Bus calls. Second, sometimes we want to block on the dispatcher response, like for pre-down.
* platform: improve tracking of route sourcesDan Winship2014-06-061-12/+12
| | | | | | | | | | | NMIP[46]Route had a "source" field, but it was always set to KERNEL for routes read from the kernel (even if they were originally added by NM). Fix things a bit by translating between our "source" field and the kernel's "protocol" field. https://bugzilla.gnome.org/show_bug.cgi?id=729203
* trivial: route-related whitespace/indentation fixesDan Winship2014-06-061-12/+36
|
* firewall: fix ZONE_CONFLICT when adding firewall interface to zoneThomas Haller2014-06-041-1/+1
| | | | | | | | | | | | | | | | | Firewalld call addInterface() fails with ZONE_CONFLICT if the interface is already part of another zone. This complicates the code in NM, because we would have to keep better track of the zone in which the interface currently is. Which might be quite difficult because the zone might be changed from an external program (so we would have to monitor the firewall configuration and work around potential races). A better and simpler fix is to simply always use the changeZone() call. This will do the right thing, regardless if the interface is already part of a zone or not. https://bugzilla.redhat.com/show_bug.cgi?id=1103782 Signed-off-by: Thomas Haller <thaller@redhat.com>
* core/firewall: fix accessing non-existing connection for device in ↵Thomas Haller2014-06-021-0/+3
| | | | | | | | | | | | | | | | | | | | | firewall_started() When starting firewall, NMPolicy would fail the following assertion: NetworkManager[1462]: <debug> [1401708294.250829] [firewall-manager/nm-firewall-manager.c:218] name_owner_changed(): firewall started (NetworkManager:1462): libnm-util-CRITICAL **: nm_connection_get_setting_connection: assertion 'NM_IS_CONNECTION (connection)' failed #0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0 #1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0 #2 0x00007f306f960e11 in nm_connection_get_setting_connection (connection=0x0) at nm-connection.c:1441 #3 0x0000000000482319 in firewall_started (manager=<optimized out>, user_data=<optimized out>) at nm-policy.c:1881 #4 0x0000003371c104c7 in _g_closure_invoke_va () from /lib64/libgobject-2.0.so.0 #5 0x0000003371c29749 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #6 0x0000003371c2a3af in g_signal_emit () from /lib64/libgobject-2.0.so.0 #7 0x0000000000445d39 in name_owner_changed (dbus_mgr=<optimized out>, name=<optimized out>, old_owner=0x1452660 "", new_owner=0x1536720 ":1.175", user_data=<optimized out>) at firewall-manager/nm-firewall-manager.c:220 ... Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: remove unused 'error' argument to check_connection_compatible()Dan Williams2014-05-301-2/+2
| | | | | Nothing uses the error, so simplify some code and save 5K (0.45%) in binary size.
* core: refactor to return const GSList * from nm_manager_get_devices()Thomas Haller2014-05-131-15/+10
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* wifi: make Wi-Fi support a pluginDan Williams2014-05-131-1/+0
| | | | | | | | | | | Make Wi-Fi support a plugin using the new device factory interface. Provides a 7% size reduction in the core NM binary. Before After NM: 1154104 1071992 (-7%) Wi-Fi: 0 110464 (all results from stripped files)
* core: add parameter to ignore error in add/remove pending actionThomas Haller2014-05-011-2/+2
| | | | | | | | | | 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>
* policy: check device state before changing it for secondaries (rh #1055099)Jiří Klimeš2014-04-151-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have to check the previous base device state in process_secondaries() when making a state change. The device might got disconnected in the meantime and thus the transition from DISCONNECTED to ACTIVATED or FAILED would have been incorrect. Logs showing the problem: NetworkManager[2655]: <info> (eth0): disconnecting for new activation request. NetworkManager[2655]: <info> (eth0): device state change: secondaries -> deactivating (reason 'none') [90 110 0] NetworkManager[2655]: <info> (eth0): device state change: deactivating -> disconnected (reason 'none') [110 30 0] NetworkManager[2655]: <info> (eth0): deactivating device (reason 'none') [0] NetworkManager[2655]: <info> (eth0): canceled DHCP transaction, DHCP client pid 11409 NetworkManager[2655]: <info> NetworkManager state is now DISCONNECTED NetworkManager[2655]: (devices/nm-device.c:6591):nm_device_state_changed: runtime check failed: (priv->in_state_changed == FALSE) NetworkManager[2655]: <info> (eth0): device state change: disconnected -> failed (reason 'secondary-connection-failed') [30 120 54] NetworkManager[2655]: <warn> Activation (eth0) failed for connection '<unknown>' NetworkManager[2655]: <warn> (eth0): add_pending_action (4): 'queued state change to disconnected' already added NetworkManager[2655]: file devices/nm-device.c: line 7682 (nm_device_add_pending_action): should not be reached NetworkManager[2655]: <info> Activation (eth0) starting connection 'ethernet-12' NetworkManager[2655]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager[2655]: <info> (eth0): device state change: failed -> disconnected (reason 'none') [120 30 0] NetworkManager[2655]: <info> (eth0): deactivating device (reason 'none') [0] NetworkManager[2655]: <warn> (eth0): remove_pending_action (2): 'queued state change to disconnected' never added NetworkManager[2655]: file devices/nm-device.c: line 7733 (nm_device_remove_pending_action): should not be reached NetworkManager[2655]: <info> VPN service 'openvpn' disappeared https://bugzilla.redhat.com/show_bug.cgi?id=1055099 https://bugzilla.redhat.com/show_bug.cgi?id=1055101
* core: fix freeing pending activations in dispose() of deviceThomas Haller2014-04-091-2/+2
| | | | | | | | | | | | | | activate_data_free() deletes the data from priv->pending_activation_checks, thus iterating over the list with g_slist_free_full() causes a double free or invalid memory access. This bug does not hit easily, because the policy only get's disposed when NM shuts down and then there are likely no pending activations queued. Fixes regression introduced by commit 4f0c70e94534abafde6a0459af74b68a7da724d9. Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: reenable auto activation for slave connections with a matching UUID masterDan Williams2014-03-051-2/+11
| | | | | | | | When activating a master, it reenables the auto activation of slave connections for this master. Do not only match the device name, but also check the connection UUID. Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: rename function nm_active_connection_get_name() to ↵Thomas Haller2014-03-051-2/+2
| | | | | | nm_active_connection_get_id() Signed-off-by: Thomas Haller <thaller@redhat.com>
* policy: fix crash caused by calling functions on connection==NULLJiří Klimeš2014-03-041-7/+12
| | | | | Crash appeared in: nm_settings_connection_set_autoconnect_blocked_reason()
* core: consolidate auto-activation recheck signalsDan Williams2014-03-031-30/+3
| | | | | | | 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.
* core: default route should stay on the current active deviceThomas Haller2014-02-271-16/+18
| | | | | | | | | | | | | get_best_ip4_device() and get_best_ip6_device() iterate over the list of devices to find the device with the default route. The order of iteration is arbitrarly choosen. Before, if two devices had the same priority, it would choose the first one. Change it so that the device which currently has the default route keeps it -- until it gets deactivated or a higher priorty device gets connected. Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: don't recursively schedule an autoactivate check on a deviceDan Winship2014-02-171-31/+25
| | | | | | | | | | | | | | | | | NMPolicy's auto_activate_device() was immediately removing the device from priv->pending_activation_checks, which meant that if nm_manager_activate_connection() had some side effect that would cause schedule_activation_check() to be called again, another auto-activation check could be queued while the first was still in progress (causing a warning). Fix this by not removing the device from the list until the activation attempt is complete. This requires some additional minor changes to correctly handle the possibility of remove_device() being triggered as a side effect of nm_manager_activate_connection(). Also merge activate_data_new() into schedule_activation_check() so that all the "start an auto-activation" code is in one place.
* Revert "core: fix warning about pending action "autoactivate""Dan Winship2014-02-171-5/+4
| | | | | | | | | This change removed the "autoactivate" pending action too soon, creating a window where the device had no pending actions, allowing the manager to declare startup complete while devices were still being activated. This reverts commit a16b7a82538e59af19557e03ae54e2e6afb5a891.
* core: remove some unused codeDan Winship2014-02-171-13/+10
| | | | | We never pass any delay_seconds value to schedule_activate_check() except "0", so just remove that argument.
* core: use nm_utils_get_monotonic_timestamp_s for autoconnect_retry_timeThomas Haller2014-01-301-4/+4
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=720833 Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: minor fix in calculating timeouts for connection retryThomas Haller2014-01-301-1/+1
| | | | | | | | The previous version is not severely wrong, it is just be better to treat connections whose retry block expires *now* as ready to reconnect. Signed-off-by: Thomas Haller <thaller@redhat.com>
* core/platform: preserve external and static route metricsDan Williams2014-01-241-12/+12
| | | | | | | | | | | | | | | | | | | Two issues: 1) routes added by external programs or by users with /sbin/ip should not be modified, but NetworkManager was always changing those routes' metrics to match the device priority. This caused the nm_platform_ipX_route_sync() functions to remove the original, external route (due to mismatched metric) and re-add the route with the NetworkManager specified metric. Fix that by not touching routes which came from the kernel. 2) Static routes (from persistent connections) that specified a metric were getting their metric overwritten with the NetworkManager device priority. Stop doing that. Since the platform no longer defaults the metric to 1024, callers of nm_platform_ip4_route_add() (like NMPolicy's default route handling) must do that themselves, if they desire this behavior.
* vpn: handle missing tunnel interface for IP-based VPNs (bgo #721724) (rh ↵Dan Williams2014-01-241-4/+11
| | | | | | | | | | | | | | | | | | | | #1030068) IPSec-based VPNs that use the kernel IPSec stack don't have tunnel interfaces, and the IP details (address, routes) get added directly to the parent network device. NetworkManager previously required a tunnel interface and failed the VPN if one was not provided. When no tunnel interface is passed, construct the VPN IP configuration using available details and pass that to the NMDevice as the VPN IP config. The device will merge that config with its own and apply any configuration that the kernel/VPN has not already applied. https://bugzilla.gnome.org/show_bug.cgi?id=721724 https://bugzilla.redhat.com/show_bug.cgi?id=1030068 https://bugzilla.redhat.com/show_bug.cgi?id=865883 https://bugzilla.redhat.com/show_bug.cgi?id=845599
* core: add some autoconnect debugging messagesDan Winship2014-01-231-8/+19
|
* core: move virtual device autoconnect tracking bits out of NMManagerDan Winship2014-01-231-2/+31
| | | | | | | | | | | Virtual devices may be created and destroyed, but we need to keep their autoconnect state across that. Previously this was handled by NMManager, but it really belongs with the other autoconnect tracking in NMPolicy and NMSettingsConnection. This also fixes a bug where NMPolicy would sometimes decide to autoactivate a virtual device connection which NMManager would then have to cancel.
* core: disable auto-re-connect of intentionally-disconnected connectionDan Winship2014-01-231-0/+4
| | | | | If a connection is disconnected by the user, don't allow it to autoconnect again immediately after.
* core: don't retry connection with no secrets after timeoutDan Winship2014-01-231-7/+0
| | | | | | | | | NMPolicy was resetting the "don't autoconnect because we don't have secrets" state on a connection when the autoconnect-retries timer timed out, but this doesn't make sense, since the timeout doesn't change the fact that there are no secrets. https://bugzilla.gnome.org/show_bug.cgi?id=670631
* core: clarify clearing of autoconnect-blocked stateDan Winship2014-01-231-3/+4
| | | | | | | NMPolicy was clearing the autoconnect-blocked state on a connection any time a device with that connection changed state. This happened to basically do the right thing, but it would be clearer if we only reset the state after successfully getting past the NEED_AUTH stage.
* core: simplify autoconnect retry handlingDan Winship2014-01-231-97/+67
| | | | | Move some of the can-autoconnect tracking into NMSettingsConnection rather than having NMPolicy track it using object data.
* core: remove useless NMSettings::connections-loaded signalDan Winship2014-01-231-14/+0
| | | | | | | | NMSettings (and NMConnectionProvider) had a signal to indicate when it had loaded the connections, but in reality this always happened before nm_settings_new() returned (as a side effect of calling unmanaged_specs_changed()) and so no one else would ever actually see the signal. So just kill it.
* core: fix warning about pending action "autoactivate"Thomas Haller2014-01-201-5/+6
| | | | | | | Fix the following warning: add_pending_action (2): 'autoactivate' already added Signed-off-by: Thomas Haller <thaller@redhat.com>
* trivial: rename field to give it a unique nameThomas Haller2014-01-201-6/+6
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: fix a possible crash if given an empty IP4 configDan Winship2014-01-161-17/+5
| | | | | | | | | | update_system_hostname() was bailing out if (there is no IP4 config or the IP4 config has no addresses) AND (there is no IP6 config or the IP6 config has no addresses), but it would then hit an assertion and crash if there was a valid IP6 config along with an IP4 config with no addresses. Fix that and get rid of some redundancy. Sort of pointed out by Coverity.
* core: reset auto-retry counter when a connection gets updatedThomas Haller2014-01-151-6/+10
| | | | | | | | | This restores the behaviour, that was removed in commit e299d7b30f7accbd83270fb1eb973fd903714d77. https://bugzilla.redhat.com/show_bug.cgi?id=1040528 Signed-off-by: Thomas Haller <thaller@redhat.com>
* dns-manager: initialize hostnameDan Winship2013-12-201-0/+1
| | | | | | | NMPolicy only updates the NMDnsManager's hostname when it changes, which previously did not include at startup. Meaning if your hostname never changed, NMDnsManager would never learn it (and so would never add an appropriate "search" line to resolv.conf). Fix that.
* dns-manager: make non-refcounted.Dan Winship2013-12-201-21/+15
| | | | | | | All the cool singletons are doing it. Also, get rid of excess nm_dns_manager_get() calls in nm-policy.c; it already has priv->dns_manager.
* policy: invoke NMPolicy::device_state_changed() after other handlers (rh ↵Jiří Klimeš2013-12-121-11/+19
| | | | | | | | | | | | | | | | | | | | | | #1033187) This fixes automatic activation after changes in commit ff7e47a41858881e102ce7c3686962f43d08cce4. When a connection is deactivated impl_manager_deactivate_connection() is called and the device goes to NM_DEVICE_STATE_DISCONNECTED. nm_device_state_changed() then issues "state-changed" signal. The signal is connected to by various listeners. The most interesting ones for this case are NMPolicy and NMActiveConnection. The problem is that NMPolicy's device_state_changed() is processed first and thus in schedule_activate_check() we still have the old active connection present (in ACTIVATED state). This commit fixes the issue by connecting to "state-changed" signal using g_signal_connect_after() in NMPolicy. This ensures NMPolicy's state-changed handler is called after active connections are processed. https://bugzilla.redhat.com/show_bug.cgi?id=1033187
View Lorry Controller Status