summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* fixup! wifi-utils: don't cache interface namebg/wext-refresh-ifname-bgo779788Beniamino Galvani2017-03-211-1/+1
|
* wifi-utils: nl80211: use logging macrosBeniamino Galvani2017-03-211-25/+35
|
* wifi-utils: wext: use logging macrosBeniamino Galvani2017-03-211-80/+89
|
* shared: increase max number of args for _NM_UTILS_MACRO_RESTBeniamino Galvani2017-03-211-2/+4
| | | | 30 should be enough for anybody.
* wifi-utils: fix use of errnoBeniamino Galvani2017-03-211-1/+3
| | | | It can be overwritten when other arguments are evaluated.
* wifi-utils: don't cache interface nameBeniamino Galvani2017-03-218-95/+143
| | | | | | | For nl80211, we don't care about the interface name and only use it when formatting error messages. For wext, an up-to-date interface name should be obtained every time to minimize the chance of race conditions when the interface is renamed.
* manager: ensure proper disposal of unrealized devicesBeniamino Galvani2017-03-211-0/+5
| | | | | | | | When remove_device() is called on an already unrealized device, we should release it from master if necessary and clear its IP configurations to avoid leaks. https://bugzilla.redhat.com/show_bug.cgi?id=1433303
* libnm/nm-vpn-connection: un-deprecate the NMVpnStateReason use in a headerThomas Haller2017-03-201-0/+2
| | | | | Otherwise merely including a header would trigger a deprecation warhing. The signal slot is not really used anyway.
* libnm: fix memleak of GUdevDevice in get_bus_name()Thomas Haller2017-03-202-0/+2
| | | | Fixes: f7b1b2820245aff26da0c2c946b55752e91112e5
* doc: fix generate-setting-docs.py for supporting Python 3 sorted() styleThomas Haller2017-03-201-7/+4
| | | | | | Python 3 has no "cmp" argument to sorted(). Fixes: b0da972f5fa51608cca5837af9fe7094818204f8
* device: add spec "driver:" to match devicesThomas Haller2017-03-177-2/+93
| | | | | | | | 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
* all: fix typos in documentation and commentsYuri Chornoivan2017-03-179-17/+17
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=780199 [thaller@redhat.com: reworded commit message]
* libnm: revert coercing NMVpnConnectionStateReason to ↵Thomas Haller2017-03-173-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | NMActiveConnectionStateReason NMVpnConnectionStateReason is no longer used and replaced by NMActiveConnectionStateReason. However, the old enums should stay in place as they were: Otherwise: #define NMVpnConnectionStateReason NMActiveConnectionStateReason causes compiler warnings: NMVpnConnectionStateReason x; x = NM_VPN_CONNECTION_STATE_REASON_UNKNOWN; // -Wenum-conversion if (x == NM_VPN_CONNECTION_STATE_REASON_NO_SECRETS) { } // -Wenum-compare Similarly, a user who didn't upgrade shall continue to get the old GType for NM_TYPE_VPN_CONNECTION_STATE_REASON. In practice, old users will have no issues using the old enum the places where it worked before. The only use of the deprecated enum is in vpn_state_changed() signal slot of NMVpnConnection. This makes the signal slot itself deprecated. However, NMVpnConnection is an NMObject and commonly created within libnm itself, not by the user. It is very unlikely that a user of libnm subclassed NMVpnConnection and makes use of the vpn_state_changed() signal slot. So, deprecate it without replacement. Fixes: a91369f80d44d1fc748fc3a9f5d9ef0fb566c77c
* trivial/whitespace: remove non-leading tabsThomas Haller2017-03-171-12/+12
|
* libnm: fix chaining up NMActiveConnection::constructed()Thomas Haller2017-03-171-0/+2
| | | | Fixes: 40ffb962bec3700e447254d4a1cc93f21b8a25dd
* merge: branch 'lr/active-connection-state-changed'Lubomir Rintel2017-03-1721-262/+408
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=779627
| * vpn-connection: use NMActiveConnectionStateReasonlr/active-connection-state-changedLubomir Rintel2017-03-176-45/+45
| |
| * libnm-core: drop NMVpnConnectionStateReasonLubomir Rintel2017-03-174-13/+35
| | | | | | | | | | It's now the same as NMActiveConnectionStateReason. Keep a compatibility typedef and enum.
| * vpn-connection: drop reason_to_stringLubomir Rintel2017-03-171-19/+0
| | | | | | | | | | | | It's utterly useless: the textual version of the reason if logged only if the plugin fails; but the plugin failure already logs the plugin state change reason which is directly translated to the connection one.
| * fixup! libnm/active-connection: track reason for state changesLubomir Rintel2017-03-172-1/+13
| |
| * cli/connections: decide about activation success and failure in single placeLubomir Rintel2017-03-171-159/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Track both device and active connections at the same time and decide whether activation finished (either successfully or not) in a single place, check_activated(). This makes the already too complex code path a bit more straightforward and also makes it possible to be more reasonable about the diagnostics. Now that the active connection signals the reason, we include it; but if the failure is due to the device disconnection while we're activating, include a device reason instead, since it's often more useful. Like: Before: Error: Connection activation failed. Without considering the device: Error: Connection activation failed: the base network connection was interrupted After: Error: Connection activation failed: The Wi-Fi network could not be found
| * libnm/active-connection: track reason for state changesLubomir Rintel2017-03-175-16/+86
| | | | | | | | | | | | | | | | | | Note that the reason tracking starts as soon as the object exists (which is immediately after GDBusObject is created), not when the asynchronous NMObject initialization finishes. That is so that we the reason changes in between are not lost. The vpn-connection should probably be doing the same.
| * active-connection: emit a StateChanged signal on state changesLubomir Rintel2017-03-179-11/+113
| | | | | | | | | | | | | | | | 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.
| * libnm-core/trivial: include literals next to NMVPNStateReason valuesLubomir Rintel2017-03-171-12/+12
| | | | | | | | | | Makes it slightly more readable, useful when we copy it to NMActiveConnectionStateReason.
| * device: cast enum types for variadic g_signal_emit() functionThomas Haller2017-03-171-1/+1
|/
* merge: branch 'lr/api-docs'Lubomir Rintel2017-03-1778-132/+595
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=779934
| * docs/libnm: add some more documentationlr/api-docsLubomir Rintel2017-03-171-18/+124
| |
| * docs/api: restructureLubomir Rintel2017-03-171-29/+105
| | | | | | | | | | This splits the manual into parts and groups the D-Bus interfaces into chapters by the object class. It looks considerably better.
| * docs/api: move D-Bus reference after nm-settingsLubomir Rintel2017-03-171-57/+57
| |
| * docs/api: make the connection settings look betterLubomir Rintel2017-03-172-22/+44
| | | | | | | | | | Turn the it into a chapter with refentries to better fit the structure of the table of contects. Also, include the properties in the index.
| * docs/api: add abstractLubomir Rintel2017-03-171-0/+20
| |
| * docs/api: add standard release informationLubomir Rintel2017-03-171-1/+5
| |
| * docs/api: reorder the manual pagesLubomir Rintel2017-03-171-4/+4
| | | | | | | | I guess the daemon and its configuration first makes most sense.
| * man: include the description for settingsLubomir Rintel2017-03-171-15/+18
| |
| * libnm/generate-setting-docs.py: include description attributeLubomir Rintel2017-03-171-3/+6
| |
| * libnm-core: sensible docstrings for NMSettings*Lubomir Rintel2017-03-1733-2/+68
| |
| * introspection: include short description everywhereLubomir Rintel2017-03-1739-0/+155
| |
| * doc: sort "connection" settings first in nm-settings manualLubomir Rintel2017-03-171-1/+9
| |
| * libnm-core/8021x: add a missing colon in gtk-docLubomir Rintel2017-03-171-1/+1
|/ | | | The universe is now perfect.
* core: merge branch 'th/assume-vs-unmanaged-bgo746440'Thomas Haller2017-03-1626-510/+904
|\ | | | | | | | | | | | | | | | | | | | | | | This branch only does part of what bgo#746440 is about. But it's a large and necessary step towards the full solution. It cleanups tracking of whether to assume a device, treat it as external or fully manage it. Future work will need to fine tune the behavior. https://bugzilla.gnome.org/show_bug.cgi?id=746440 https://bugzilla.redhat.com/show_bug.cgi?id=1394579
| * device: track system interface state in NMDeviceThomas Haller2017-03-167-91/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * manager: always cleanup volatile settings-connection on active-connection ↵Thomas Haller2017-03-161-2/+1
| | | | | | | | | | | | | | removal This is not only relevant if the active connection is assumed/external.
| * manager: simplify searching assumed connectionThomas Haller2017-03-164-39/+61
| | | | | | | | | | | | Now we only search for a candiate with matching UUID. No need to first lookup all activatable connections, just find the candidate by UUID and see if it is activatable.
| * manager: cleanup find_ac_for_connection() in "nm-manager.c"Thomas Haller2017-03-161-40/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
| * manager: merge/inline assume_connection() in recheck_assume_connection()Thomas Haller2017-03-161-62/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
| * core: once activated an assumed connection make it NM_ACTIVATION_TYPE_MANAGEDThomas Haller2017-03-161-0/+10
| |
| * core: upgrade EXTERNAL activation type when user saves connectionThomas Haller2017-03-161-6/+45
| | | | | | | | | | | | An EXTERNAL activation type comes with a nm-generated, volatile, in-memory connection. When the user actively modifies that connection, we shall mark the active connection as fully managed.
| * core: only assume connections that were managed in a previous run of ↵Thomas Haller2017-03-161-30/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NetworkManager Before, we would have the concept of assumed connections, which is used for (1) externally configured device that NetworkManager should not touch and (2) connections that NetworkManager should gracefully take over after a restart (seamlessly, non-destructively). The behavior was unclear and mixed. It wasn't clear whether the device is in no-touch mode (1) or gracefully take-over (2). Previous commits already introduce separate activation types EXTERNAL (1) and ASSUME (2). Also, previously, we would for both (1) and (2) try to find a matching connection and use it. That doesn't make sense for either. In the external case (1), we should not pretend that an existing connection is active. Let's always create a new in-memory connection for these cases. Note that this means, external devices now will always generate a connection, instead of pretending an existing one is active. For the assume case (2), we shall not use nm_utils_match_connection() to guess which connection might be active. It can only the one that was active on a previous run of NetworkManager. So, use the information from the state file and try to activate it. If that fails, it is not an assume activation type. Note, that this means we now most of the time don't do ASSUME anymore. Most of the time we do EXTERNAL activation That is because the state information is only available after restart of NetworkManager.
| * core: track external activations types in the active-connectionThomas Haller2017-03-166-40/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need a distinction between external activations and assuming connections. The former shall have the meaning of devices that are *not* managed by NetworkManager, the latter are configurations that are gracefully taken over after restart (but fully managed). Express that in the activation-type of the active connection. Also, no longer use the settings NM_SETTINGS_CONNECTION_FLAGS_VOLATILE flag to determine whether an assumed connection is "external". These concepts are entirely orthogonal (although in pratice, external activations are in-memory and flagged as volatile, but the inverse is not necessarily true). Also change match_connection_filter() to consider all connections. Later, we only call nm_utils_match_connection() for the connection we want to assume -- which will be a regular settings connection, not a generated one.
| * core/trivial: rename activation-type related checks for device and ↵Thomas Haller2017-03-167-40/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | active-connection nm_device_uses_assumed_connection() basically called nm_active_connection_get_assumed() on the device. Rename those functions to be closer to the activation-type flags. The concepts of "assume", "external", and "assume_or_external" will make sense with the following commits.
View Lorry Controller Status