summaryrefslogtreecommitdiff
path: root/src/nm-manager.c
Commit message (Collapse)AuthorAgeFilesLines
* bluetooth: refactor BlueZ handling and let NMBluezManager cache ↵Thomas Haller2019-09-231-20/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObjectManager data This is a complete refactoring of the bluetooth code. Now that BlueZ 4 support was dropped, the separation of NMBluezManager and NMBluez5Manager makes no sense. They should be merged. At that point, notice that BlueZ 5's D-Bus API is fully centered around D-Bus's ObjectManager interface. Using that interface, we basically only call GetManagedObjects() once and register to InterfacesAdded, InterfacesRemoved and PropertiesChanged signals. There is no need to fetch individual properties ever. Note how NMBluezDevice used to query the D-Bus properties itself by creating a GDBusProxy. This is redundant, because when using the ObjectManager interfaces, we have all information already. Instead, let NMBluezManager basically become the client-side cache of all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned about caching the D-Bus interface's state, tracking suitable profiles (pan_connection), and moderate between bluez and NMDeviceBt. These tasks don't get simpler by moving them to a seprate file. Let them also be handled by NMBluezManager. I mean, just look how it was previously: NMBluez5Manager registers to ObjectManager interface and sees a device appearing. It creates a NMBluezDevice object and registers to its "initialized" and "notify:usable" signal. In the meantime, NMBluezDevice fetches the relevant information from D-Bus (although it was already present in the data provided by the ObjectManager) and eventually emits these usable and initialized signals. Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and NMBluezDevice are strongly cooperating to the point that it is simpler to merge them. This is not mere refactoring. This patch aims to make everything asynchronously and always cancellable. Also, it aims to fix races and inconsistencies of the state. - Registering to a NAP server now waits for the response and delays activation of the NMDeviceBridge accordingly. - For NAP connections we now watch the bnep0 interface in platform, and tear down the device when it goes away. Bluez doesn't send us a notification on D-Bus in that case. - Rework establishing a DUN connection. It no longer uses blocking connect() and does not block until rfcomm device appears. It's all async now. It also watches the rfcomm file descriptor for POLLERR/POLLHUP to notice disconnect. - drop nm_device_factory_emit_component_added() and instead let NMDeviceBt directly register to the WWan factory's "added" signal.
* libnm: export reload flagsBeniamino Galvani2019-09-171-4/+4
| | | | | Flags to the manager Reload() method are stable API but not exposed in a public header. Export them.
* all: SPDX header conversionLubomir Rintel2019-09-101-14/+1
| | | | | $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
* core: add defines for common authentication-related error messagesBeniamino Galvani2019-09-051-14/+14
| | | | | | All D-Bus method call implementations use similar error messages when authenticating requests; add defines for them to ensure the same exact message is reused.
* manager: keep device if realize() failsBeniamino Galvani2019-09-031-1/+0
| | | | | | | | | system_create_virtual_device() first creates the device (unrealized) and then, if there a connection for the device with autoconnect=yes, creates the backing resources. If this last step fails the device should continue to exist, even if in an unrealized state. https://bugzilla.redhat.com/show_bug.cgi?id=1686634
* shared: add nm_c_list_elem_find_first() helper macroThomas Haller2019-08-081-1/+1
| | | | | | | | | | | | | - add nm_c_list_elem_find_first() macro that takes a predicate and returns the first match. This macro has a non-function-like behavior, which we often try to avoid because macros should behave like functions. In this case it's however convenient, so let's do it. Also, despite being non-function-like, it should be pretty hard to use wrongly. - rename nm_c_list_elem_find_first() to nm_c_list_elem_find_first_ptr().
* manager: don't treat the initramfs-configured DHCP connections as generatedLubomir Rintel2019-08-021-6/+40
| | | | | | | | | | | | | | These are special -- initramfs configured them and killed dhclient. Bad things would happen if we let the addresses expire though. Let's act as if initramfs actually passed the configuration to us. It actually tries to do so by the means of writing an ifcfg file, but that one is too broken to be useful, so the ifcfg-rh plugin ignores it. Notably, it doesn't have the actual addresses or correct BOOTPROTO. The generated connection is better. Co-authored-by: Thomas Haller <thaller@redhat.com> (cherry picked from commit acf3e0092ad8d52ef54644d63c8e4f7f974847c7)
* settings/trivial: rename NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK to ↵Thomas Haller2019-07-251-2/+2
| | | | | | | NM_SETTINGS_CONNECTION_PERSIST_MODE_TO_DISK NM_SETTINGS_CONNECTION_PERSIST_MODE_DISK really directly corresponds to NM_SETTINGS_UPDATE2_FLAG_TO_DISK. Rename, so that this is better reflected.
* core,libnm: add AddConnection2() D-Bus API to block autoconnect from the startThomas Haller2019-07-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
* libnm,core: Add ConnectivityCheckUri property and accessorsIain Lane2019-07-221-2/+19
| | | | | | | So that applications like GNOME Shell can hit the same URI to show the captive portal login page. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/209
* settings: rework tracking settings connections and settings pluginsThomas Haller2019-07-161-55/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
* core: use nm_c_list_elem_free_steal() in _delete_volatile_connection_all ()Thomas Haller2019-07-101-3/+1
|
* manager: propagate the for-user-request flag for slaves autoconnectionBeniamino Galvani2019-07-081-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the master is activated by user, propagate the for-user-request to slaves activations when autoconnecting slaves, so that they can manage slaves device as needed. Reproducer: ip l add eth1 type veth peer name eth2 ip l set eth1 up ip l set eth2 up sleep 2 echo " * Initial state" echo " - eth1: $(nmcli -g general.state device show eth1)" nmcli con add type ethernet ifname eth1 con-name slave-test+ master br-test slave-type bridge nmcli con add type bridge ifname br-test con-name br-test+ connection.autoconnect-slaves yes ip4 172.25.1.1/24 nmcli con up br-test+ echo " * After user activation" echo " - br-test: $(nmcli -g general.state device show br-test)" echo " - eth1: $(nmcli -g general.state device show eth1)" should give: * Initial state - eth1: 10 (unmanaged) * After user activation - br-test: 100 (connected) - eth1: 100 (connected)
* core: create virtual device on settings changes in idle handlerThomas Haller2019-07-021-2/+49
| | | | | | | The callback from NMSettings about adding/updating a settings comes from a deep call-stack already. We don't know the context of it, and we shouldn't just right away create the profile. Instead, schedule an action to create it in an idle handler.
* manager: don't consider by-user change flag for creating unrealized deviceThomas Haller2019-06-261-3/+8
| | | | | | | | | | | | | | | | | | | | This effectively reverts commit [1]. The by-user argument is not very clear what it means. Is a "nmcli connection load $FILENAME" a user-action? How about reload? I don't know whether the problem that this was supposed to fix is still present. But in any case, the condition here seems not right. It's already hard to understand when and how we generate unrealized devices. If the condition from commit [1] should be prevented, then it must happen somehow differently. In the example, the offending connection is a generated volatile profile with the device being sys-face-state "external". Of course, we should not generate devices for such profiles nor autoactivating them. So adding a device for a volatile connection is always wrong. Don't do that, which should avoid the original problem. [1] commit a8a4eb14183b ('manager: don't create the virtual devices on all connection changes')
* core: ensure normalized connection during add-and-activateThomas Haller2019-06-261-0/+2
| | | | | | | nm_connection_verify() returns success for fully valid (normalized) connections and also connections that are NM_SETTING_VERIFY_NORMALIZABLE. We really want to fully normalize the profiles during add-and-activate.
* settings: reorder checks in _delete_volatile_connection_do() to perform ↵Thomas Haller2019-06-261-2/+2
| | | | | | | cheaper check first Checking whether a settings connection is still tracked is a simple c_list_is_empty(). It's faster, so do it first.
* settings: use NMCListElem instead of DeleteVolatileConnectionData for ↵Thomas Haller2019-06-261-18/+6
| | | | | | | tracking connections to delete For tracking a CList of one pointer we have NMCListElem API. We don't need to implement our own struct to hold the list pointers and the data pointer.
* manager: cleanup freeing CList in NMManager's dispose()Thomas Haller2019-06-131-6/+6
| | | | | To unlink all elements, I find a while() loop easier to read than c_list_for_each_*safe().
* auth-chain: track auth-chains in embedded CListThomas Haller2019-06-131-28/+27
| | | | | | | | | | | | | | | | | | | NMManager and NMSettings both may have multiple authorization requests ongoing. They need to keep track of them, at the very least to be able to cancel them on shutdown. Since NMAuthChain is not ref-countable, it always has only one clear user/owner. It makes little sense otherwise. Since most callers already want to track their NMAuthChain instances, let NMAuthChain help with that. Embed a "parent" CList field inside NMAuthChain. This avoids requiring an additional GSList allocation to track the element. Also, it allows to link and append an element without iterating the list. This ties the caller and the NMAuthChain a bit tighter together (making them less indepdendent). Generally that is not desirable. But here it seems the logic (of tracking the NMAuthChain) is still trivial and well separated. It's just that NMAuthChain instances now can be linked in a CList.
* all: drop emacs file variables from source filesThomas Haller2019-06-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | We no longer add these. If you use Emacs, configure it yourself. Also, due to our "smart-tab" usage the editor anyway does a subpar job handling our tabs. However, on the upside every user can choose whatever tab-width he/she prefers. If "smart-tabs" are used properly (like we do), every tab-width will work. No manual changes, just ran commands: F=($(git grep -l -e '-\*-')) sed '1 { /\/\* *-\*- *[mM]ode.*\*\/$/d }' -i "${F[@]}" sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}" Check remaining lines with: git grep -e '-\*-' The ultimate purpose of this is to cleanup our files and eventually use SPDX license identifiers. For that, first get rid of the boilerplate lines.
* config: also save next-server in the state fileLubomir Rintel2019-05-301-1/+5
| | | | | | | | | The early boot tooling gets the root-path from our state file due to a lack of a better way to do that. However, when booting with NFS root, the root path alone is not sufficient; the server address is communicated via the next-server option. Save that one in the state file as well. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
* utils: add ifname argument to nm_utils_complete_generic()Lubomir Rintel2019-05-281-0/+1
| | | | | | It's a common thing to complete a connection with an interface name; adding it to the common path is goint to save as a few tens of lines later on.
* manager: relax condition when checking for duplicate ACsBeniamino Galvani2019-05-201-3/+1
| | | | | | | An active connection started by user could be queued in state UNKNOWN which means the device hasn't started activating yet. Eventually it will, and we don't want to cancel the user activation because of an internal autoconnection attempt.
* manager: don't allow femoving a device without traversing proper statesLubomir Rintel2019-05-201-14/+13
| | | | | | | | | | | | | | | | There was a special case for ensuring that the device's configuration doesn't disappear when some factory is too late at recognizing the device is just a component of another one. It was always a bad idea. If the device already had an active connection (such as for a generated default wired connection), it would remain around, with a dangling reference to the device. This effectively reverts commit 5ad69cb29b7c ('core: remove child devices without deconfiguring them (bgo #738479)'). It's okay to do so, because we now wouldn't deconfigure the device upon its removal anyway. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
* core: don't log plain pointer values for singletonsThomas Haller2019-05-131-1/+2
| | | | Logging pointer values allows to defeat ASLR. Don't do that.
* manager: use "perm" name for nm_auth_chain_set_data() tag in ↵Thomas Haller2019-05-121-2/+2
| | | | | | | | | device_auth_request_cb() There are two similar cases where the caller attaches the requested permission to the auth-chain. There the tag "perm" is used. Rename for consistency.
* auth-chain: don't clone the permission string for AuthChainThomas Haller2019-05-121-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | Out of the 33 callers of nm_auth_chain_add_call(), the permission argument is: - 29 times a C string literal like NM_AUTH_PERMISSION_NETWORK_CONTROL. - 3 times assign a string that is in fact a static string (it's just not a string literal) - only NMManager's device_auth_request_cb() passes a permission of (possibly) non static origin. But it already duplicates the string for it's own purposes and attaches it as user-data to the NMAuthChain. There really is no need to duplicate the string. Replace nm_auth_chain_add_call() by a macro that ensures that the permission string is a C literal. Rename nm_auth_chain_add_call() to nm_auth_chain_add_call_unsafe() to indicate that the lifetime of the permission argument is now the responsibility of the caller.
* core: remove unused error argument from NMAuthChainResultFuncThomas Haller2019-05-121-66/+10
| | | | | | | | | | | | | | NMAuthChain usually requests several permissions at once. Hence, an error argument in the overall callback does not make sense, because you wouldn't know which request failed. If at all, it could only mean that the overall request failed (like an D-Bus failure communicating to D-Bus *for all permisssions*), but we don't need to handle that specially. In fact, we don't really care why permission was not granted, whether it's due to an error or legitimate reasons. The error in the callback was always set to %NULL. Remove it.
* core: don't call nm_auth_chain_destroy() from the callbackThomas Haller2019-05-121-57/+38
| | | | | | | | | | | | | | | | | | | NMAuthChain is not ref-counted. You may call nm_auth_chain_destroy() once before the callback gets invoked. This destroys the auth-chain instance right away. You may call nm_auth_chain_destroy() once from inside the callback. This basically has no effect but is allowed for convenince. All this does is remembering that destroy was called and asserts that destroy gets called at most once. After the callback returns, the auth-chain will always be destroyed. That means, generally there is no need to call nm_auth_chain_destroy() from inside the callback. Remove that code, and refactor some code to return early (where it makes sense).
* core: drop unused function sleep_auth_done_cb()Thomas Haller2019-05-121-39/+0
| | | | | | This function was left as a reminder now for 9 years. Get rid of it. Related: 8310593ce48a ('core: ignore authorization for sleep/wake requests (but restrict to root) (rh #638640)')
* settings: cache keyfile databases for "timestamps" and "seen-bssids"Thomas Haller2019-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Only read the keyfile databases once and cache them for the remainder of the program. - this avoids the overhead of opening the file over and over again. - it also avoids the data changing without us expecting it. The state files are internal and we don't support changing it outside of NetworkManager. So in the base case we read the same data over and over. In the worst case, we read different data but are not interested in handling the changes. - only write the file when the content changes or before exiting (normally). - better log what is happening. - our state files tend to grow as we don't garbage collect old entries. Keeping this all in memory might be problematic. However, the right solution for this is that we come up with some form of garbage collection so that the state files are reaonsably small to begin with.
* manager: unmanage software devices when networking gets disabledBeniamino Galvani2019-04-241-3/+9
| | | | | | If a user disables networking, we consider that as an indication that also software devices must be disconnected. OTOH, we don't want to destroy them for external events as a system suspend.
* manager: clear unmanaged-sleeping flag on software devices on resumeBeniamino Galvani2019-04-241-4/+4
| | | | | | | When networking is disabled at NM startup we unmanage all devices (including software ones) due to SLEEPING. After networking gets enabled again we must clear the unmanaged-sleeping flag on software devices.
* shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-coreThomas Haller2019-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "libnm-core" implements common functionality for "NetworkManager" and "libnm". Note that clients like "nmcli" cannot access the internal API provided by "libnm-core". So, if nmcli wants to do something that is also done by "libnm-core", , "libnm", or "NetworkManager", the code would have to be duplicated. Instead, such code can be in "libnm-libnm-core-{intern|aux}.la". Note that: 0) "libnm-libnm-core-intern.la" is used by libnm-core itsself. On the other hand, "libnm-libnm-core-aux.la" is not used by libnm-core, but provides utilities on top of it. 1) they both extend "libnm-core" with utlities that are not public API of libnm itself. Maybe part of the code should one day become public API of libnm. On the other hand, this is code for which we may not want to commit to a stable interface or which we don't want to provide as part of the API. 2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core" and thus directly available to "libnm" and "NetworkManager". On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm" and "NetworkManager". Both libraries may be statically linked by libnm clients (like nmcli). 3) it must only use glib, libnm-glib-aux.la, and the public API of libnm-core. This is important: it must not use "libnm-core/nm-core-internal.h" nor "libnm-core/nm-utils-private.h" so the static library is usable by nmcli which couldn't access these. Note that "shared/nm-meta-setting.c" is an entirely different case, because it behaves differently depending on whether linking against "libnm-core" or the client programs. As such, this file must be compiled twice. (cherry picked from commit af07ed01c04867e281cc3982a7ab0d244d4f8e2e)
* shared: move "nm-dbus-compat.h" header to "nm-std-aux/nm-dbus-compat.h"Thomas Haller2019-04-181-1/+1
| | | | (cherry picked from commit 81833358786b0fdd0668ef92b0bdc1361fa980b3)
* shared: move most of "shared/nm-utils" to "shared/nm-glib-aux"Thomas Haller2019-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the files under "shared/nm-utils" we build an internal library that provides glib-based helper utilities. Move the files of that basic library to a new subdirectory "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la" to "libnm-glib-aux.la". Reasons: - the name "utils" is overused in our code-base. Everything's an "utils". Give this thing a more distinct name. - there were additional files under "shared/nm-utils", which are not part of this internal library "libnm-utils-base.la". All the files that are part of this library should be together in the same directory, but files that are not, should not be there. - the new name should better convey what this library is and what is isn't: it's a set of utilities and helper functions that extend glib with funcitonality that we commonly need. There are still some files left under "shared/nm-utils". They have less a unifying propose to be in their own directory, so I leave them there for now. But at least they are separate from "shared/nm-glib-aux", which has a very clear purpose. (cherry picked from commit 80db06f768e47541eae7d66ef48fbe47bf1a69ce)
* core: don't realize unmanaged software devicesbg/unmanaged-sw-dev-rh1679230Beniamino Galvani2019-04-121-0/+7
| | | | | | | | | | | | | | | | | | | | Currently, if user configuration or settings specify that a software device is unmanaged, for example: [device-bond-unmanaged] match-device=interface-name:bond* managed=0 or [keyfile] unmanaged-devices=interface-name:bond* and there is a connection for the device with autoconnect=yes, NM creates the platform link and a realized device in unmanaged state. Fix this, the device should not be realized if it is unmanaged. https://bugzilla.redhat.com/show_bug.cgi?id=1679230
* Update connectivity value on device removalAntonio Larrosa2019-04-021-0/+10
| | | | | | | | | | | | | | | | | | | | | When a device is removed (like when the user unplugs a usb network device) the device object is removed, so it doesn't emit a notify signal for a change in its connectivity and so, device_connectivity_changed is not called. This means that nobody updates the global connectivity value which is potentially wrong if the device was the one providing network connectivity. Since device_connectivity_changed's first two parameters aren't actually used and are there just for the signal to be able to be connected, I moved the code from device_connectivity_changed to a new update_connectivity_value function that just takes a NMManager parameter and also call it from remove_device. [thaller@redhat.com: fix coding style regarding whitespace] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/141 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/101
* trivial: fix grouping of empty GClosure arg in g_signal_new()Francesco Giudici2019-03-221-4/+4
|
* manager: ignore ovs-system master when assuming connectionsBeniamino Galvani2019-03-041-1/+6
| | | | | | | | This change allows NM to assume after a restart a device that has been enslaved externally to an ovs bridge. https://bugzilla.redhat.com/show_bug.cgi?id=1676551 (cherry picked from commit 93bbe436958264d5f720ce095b3f390ce50fc732)
* all: replace g_strerror() calls with nm_strerror_native()Thomas Haller2019-02-121-1/+1
|
* all: cache errno in local variable before using itThomas Haller2019-02-121-2/+3
|
* all: drop unnecessary includes of <errno.h> and <string.h>Thomas Haller2019-02-121-2/+0
| | | | | "nm-macros-interal.h" already includes <errno.h> and <string.h>. No need to include it everywhere else too.
* manager: Fix GVariant format strings for AddAndActivate2 return valueBenjamin Berg2019-01-291-2/+2
| | | | | | | | | | AddAndActivate2 returns an empty a{sv} dictionary for extensibility. The format strings to create the methods return value were slightly wrong, causing assertion failures. Fixes: fbb038af5e5d675c994de26da676edfd8e73ffbe https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/73
* all: fix misspellingsRafael Fontenelle2019-01-241-4/+4
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/64
* all: return output dictionary from "AddAndActivate2"Thomas Haller2019-01-141-9/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876
* core: cleanup error path in activation_add_done()Thomas Haller2019-01-141-23/+28
| | | | | | | Don't return success from a nested code path. Handle all errors first, and return early. Well, we cannot really return right away because we need to handle the failure. So, at least, check for errors and "goto fail".
* connectivity: consider default route for global connectivity stateThomas Haller2018-12-111-28/+75
| | | | | | | | | | | | | | | When we agregate the connectivity state, only devices that have the best default route should be considered. Since we do connectivity checking per-device, the per-device check does not care whether traffic to the internet is really routed via this device. But when talking about the global connectivity state, we care mostly about the (best) default route. So, we should not allow a device with worse or now default route, to contribute its connectivity state. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39
* connectivity: fix determining the global connectivity stateThomas Haller2018-12-111-2/+5
| | | | | | | | | | | | | | | | | | | Since we determine the connectivity state of each device individually, the global connectivity state is an aggregate of all these states. I am not sure about considering here devices that don't have the (best) default route for their respective address family. But anyway. When we aggregate the best connectivity, we chose the numerical largest value. That is wrong, because PORTAL is numerically smaller than LIMITED. That means, if you have two devices, one with connectivity LIMITED and one with connectivity PORTAL, then LIMITED wrongly wins. Fixes: 6b7e9f9b225e81d365fd95901a88a7bc59c1eb39 https://bugzilla.redhat.com/show_bug.cgi?id=1619873
View Lorry Controller Status