summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* platform: add generic NM_PLATFORM_IP_ROUTE_CAST() macroThomas Haller2017-11-131-16/+4
| | | | A cast macro, that does some static type checking (of the pointer).
* core: use NM_CONSTCAST() for NM_IP_CONFIG_CAST()Thomas Haller2017-11-132-27/+45
|
* shared: propagate constness in _NM_GET_PRIVATE_PTR()Thomas Haller2017-11-132-3/+3
| | | | | | | | The _NM_GET_PRIVATE() macro already preserved and propagated the constness of @self to the resulting private pointer. _NM_GET_PRIVATE_PTR() didn't do that. Extend the macro, to make that possible.
* core: fix build without connectivity checkBeniamino Galvani2017-11-122-1/+12
| | | | | | Fixes: 4dd30b784c53e9b61b6e3a2b2e135f589747fc06 https://bugzilla.gnome.org/show_bug.cgi?id=790222
* device: silent compiler warningBeniamino Galvani2017-11-101-1/+1
| | | | | | | | | Fix the following warning: src/devices/nm-device.c: In function ‘activation_source_schedule’: src/devices/nm-device.c:4995:9: error: ‘source_func’ may be used uninitialized in this function [-Werror=maybe-uninitialized] new_id = g_idle_add (source_func, self); ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* ofono: refactor error handling in context_property_changed()Thomas Haller2017-11-101-76/+58
|
* ofono: fix creating IP config with proper ifindex of InterfaceThomas Haller2017-11-101-20/+8
| | | | | This was broken with the routing-rework. We need to determine the ifindex on which the configuration applies.
* ofono: refactor error handling for missing Interface in ↵Thomas Haller2017-11-101-12/+12
| | | | context_property_changed()
* ofono: fix leaks in context_property_changed()Thomas Haller2017-11-101-3/+2
|
* device: add a new state-reason for DAD failuresBeniamino Galvani2017-11-091-2/+3
|
* device: don't necessarily fail the connection when ipv4 DAD failsBeniamino Galvani2017-11-091-4/+4
| | | | | | | | Don't necessarily fail the entire connection if a duplicate IPv4 address is detected, but instead look at the may-fail property and at the outcome of IPv6. https://bugzilla.redhat.com/show_bug.cgi?id=1508001
* all: update compatiblity for older libjansson versionsth/janssonThomas Haller2017-11-091-0/+4
| | | | | | | | | | | - nm-ovsdb.c uses json_load_callback(), which is jansson v2.4. Hence, it cannot build the OVS plugin in our Travis-CI, which is still on Ubuntu Precise. Disable building the plugin in travis and add a compiler warning when building against an older version. - since jansson v2.3, there is json_object_key_to_iter() to implement the for-each macros. Use it in json_object_foreach_safe() when available.
* all: use nm-jansson.hThomas Haller2017-11-092-23/+2
|
* shared: make NM_CONSTCAST() macro variadicThomas Haller2017-11-093-11/+11
| | | | | | | | | | | | | | We need to pass more alias-types. Instead of having numbered versions, use variadic number of macro arguments. Also, fix build failure with old compiler: In file included from src/nm-ip6-config.c:24: ./src/nm-ip6-config.h:44:29: error: controlling expression type 'typeof (ipconf_iter->current->obj)' (aka 'const void *const') not compatible with any generic association type *out_address = has_next ? NMP_OBJECT_CAST_IP6_ADDRESS (ipconf_iter->current->obj) : NULL; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: b1810d7a68d188aa8f36a0e23a7be705a742b1aa
* shared: rework _NM_GET_PRIVATE() to use _Generic()Thomas Haller2017-11-092-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | _NM_GET_PRIVATE() used typeof() to propagate constness of the @self pointer. However, that means, it could only be used with a self pointer of the exact type. That means, you explicitly had to cast from (GObject *) or from (void *). The requirement is cumbersome, and often led us to either create @self pointer we didn't need: NMDeviceVlan *self = NM_DEVICE_VLAN (device); NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE (self); or casting: NMDeviceVlanPrivate *priv = NM_DEVICE_VLAN_GET_PRIVATE ((NMDevice *) device); In both cases we forcefully cast the source variable, loosing help from the compiler to detect a bug. For "nm-linux-platform.c", instead we commonly have a pointer of type NMPlatform. Hence, we always forcefully cast the type via _NM_GET_PRIVATE_VOID(). Rework the macro to use _Generic(). If compiler supports _Generic(), then we will get all compile time checks as desired. If the compiler doesn't support _Generic(), it will still work. You don't get the compile-time checking of course, but you'd notice that something is wrong once you build with a suitable compiler.
* core: export checkpoint list over D-BusBeniamino Galvani2017-11-094-4/+61
|
* checkpoint: track checkpoints in a listBeniamino Galvani2017-11-091-27/+41
| | | | | Checkpoints will be exported over D-Bus and they must be presented in a predictable order. Keep them in a list ordered by creation time.
* checkpoint: don't include unrealized devicesBeniamino Galvani2017-11-093-24/+17
| | | | | | | | Don't include unrealized devices in checkpoint because, as the name says, they are not real. While at it, remove nm_manager_get_device_paths() as it is no longer used.
* checkpoint: specify path of already existing checkpoint on errorBeniamino Galvani2017-11-091-3/+5
|
* core: merge IPv4 and IPv6 implementations in NMDnsManagerth/dns-ip-config-unifyThomas Haller2017-11-092-208/+95
|
* core: add NMIPConfig helpersThomas Haller2017-11-092-6/+86
| | | | | | For now, hack some generic accessors to the NMIP4Config/NMIP6Config type. Eventually, NMIP4Config and NMIP6Config should get merged in one class.
* core: replace nm_dns_ip_config_data_get_dns_priority()Thomas Haller2017-11-085-22/+21
| | | | | Add instead nm_ip_config_get_dns_priority(). If we want to treat NMIP4Config/NMIP6Config generically, then the accessor should be right there.
* core: add generic opaque NMIPConfig typeThomas Haller2017-11-082-0/+34
| | | | | One day, I hope to merge NMIP4Config and NMIP6Config implementations. A small step, and a typesafe cast-macro.
* policy: merge IPv4 and IPv6 implementation of update_ip_dns()Thomas Haller2017-11-083-101/+52
|
* policy: don't block autoconnect for connections when disconnecting software ↵th/autoconnect-rh1401515Thomas Haller2017-11-081-39/+6
| | | | | | | | | | | | | | | | | devices This was added by commit 979b8920b465867ea248dee23a8a290da28f75e5 (core: move virtual device autoconnect tracking bits out of NMManager) to avoid autoconnecting software devices repeatedly. That was done, because disconnecting a software device would delete the NMDevice instance, and there is no property on a device to prevent autoconnect. In the meantime, we only unrealize software devices and don't delete them entirely. Also, the autoconnect-blocked flags of the device are preserved when the device unrealized. It was anyway odd, that deactivating one software-device would block autoconnection for all matching connections.
* device: improve tracking autoconnect-blocked flags of NMDeviceThomas Haller2017-11-085-23/+20
| | | | | | | | | | | | | | | | | | | | | | | | | - split NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN in two parts: "wrong-pin" and "manual-disconnect". Setting/unsetting them should be tracked differently, as their reason differs. - no longer initialize/clear the autoconnect-blocked reasons during realize/unrealize of the device. Instead, initialize it once when the object gets created (nm_device_init()), and keep the settings beyond unrealize/realize cycles. This only matters for software devices, as regular devices get deleted after unrealizing once. But for software devices it is essential, because we don't want to forget the autoconnect settings of the device instance. - drop verbose logging about blocking autoconnect due to failed pin. We already log changes to autoconnect-blocked flags with TRACE level. An additional message about this particular issue seems not necessary at INFO level. - in NMManager's do_sleep_wake(), no longer block autoconnect for devices during sleep. We already unmanage the device, which is a far more effective measure to prevent activation. We should not also block autoconnect.
* device: refactor autoconnect blocking by introducing ↵Thomas Haller2017-11-086-53/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | NMDeviceAutoconnectBlockedFlags enum The flags allow for more then two reasons. Currently the only reasons for allowing or disallowing autoconnect are "user" and "intern". It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative meaning. So nm_device_set_autoconnect_intern (device, FALSE); gets replaced by nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN); and so on. However, it's chosen this way, because autoconnect shall be allowed, unless any blocked-reason is set. That is, to check whether autoconnect is allowed, we do if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL)) The alternative check would be if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) which seems odd too. So, add the inverse flags to block autoconnect. Beside refactoring and inverting the meaning of the autoconnect settings, there is no change in behavior.
* policy: don't check autoconnect flag of connection in ↵Thomas Haller2017-11-081-6/+0
| | | | | | | | | | | | | | | | | nm_device_can_auto_connect() nm_device_can_auto_connect() only has one caller, auto_activate_device() in NMPolicy. That caller already checks whether the connection has autoconnect enabled, so drop the duplicate check. This saves some duplication, but it also makes some sense: NMSettingsConnection has a complex blocking of autoconnect, so just looking at connection.autoconnect is not enough in any case to determine whether the connection should autoconnect. We move thus more handling of autoconnect to NMPolicy, where it belongs.
* policy: refactor auto_activate_device() to return earlyThomas Haller2017-11-081-37/+37
|
* policy: optimize nm_device_can_auto_connect() to not check ↵Thomas Haller2017-11-082-2/+11
| | | | nm_device_autoconnect_allowed()
* device: minor refactoring of condition in nm_device_autoconnect_allowed()Thomas Haller2017-11-081-3/+6
| | | | Makes it clearer what is happening (to me).
* device/olpc-mesh: reject autoconnect requests early via ↵Thomas Haller2017-11-081-5/+2
| | | | | | | | get_autoconnect_allowed() OLPC devices cannot autoconnect, according to can_auto_connect(). We should instead reject any attempt to autoconnect earlier, via get_autoconnect_allowed().
* device: inline NMDevice's implementation of can_auto_connect()Thomas Haller2017-11-082-13/+18
| | | | | Derived classes should not modify or overwrite this essential behavior of can_auto_connect(). It doesn't belong to the virtual function.
* policy: remove redundant check in device_autoconnect_changed()Thomas Haller2017-11-081-4/+2
| | | | | schedule_activate_check() also checks for nm_device_autoconnect_allowed() and aborts if there is nothing to do.
* device: move nm_device_get_enabled() from schedule_activate_check() to ↵Thomas Haller2017-11-082-3/+3
| | | | nm_device_autoconnect_allowed()
* device: drop stub implementation of get_autoconnect_allowed() in NMDeviceThomas Haller2017-11-082-12/+5
|
* ifcfg-rh: persist the connection type for TeamPort connectionsBeniamino Galvani2017-11-064-3/+77
| | | | | | | | | | Currently the ifcfg-rh plugin doesn't explicitly store the connection type for team slaves and is only able to read back ethernet and vlan connections. Leave this unchanged for ethernet and vlan slaves, but store the TYPE variable for other connection types (Wi-Fi and Infiniband) so that we can properly determine their type when the connection is read.
* logging: configure dnsmasq's logging in shared mode via nm-loggingThomas Haller2017-11-061-1/+2
|
* ndisc: fix ordering of gatewaysBeniamino Galvani2017-11-032-5/+66
| | | | | | | | | Insert the new gateway at the end when it has the least preference. Fixes the following runtime error: src/ndisc/nm-ndisc.c:204:_ASSERT_data_gateways: assertion failed: (_preference_to_priority (item_prev->preference) >= _preference_to_priority (item->preference))
* wifi: use connection.auth-retries to handle authentication in NMDeviceWifiThomas Haller2017-11-021-27/+4
|
* device: move tracking auth_retry to NMDeviceThomas Haller2017-11-024-42/+24
| | | | | It will be also used by NMDeviceWifi. It might waste a 4 bytes for device types that don't require authentication. But it deduplicates code.
* ifcfg-rh: use svSetValueInt64_cond() in write_connection_setting()Thomas Haller2017-11-021-13/+11
|
* all: move setting 802-1x.auth-retries to connection.auth-retriesThomas Haller2017-11-026-40/+37
| | | | | | | | | | | The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
* ifcfg-rh: refactor write_object() to avoid coverity warningThomas Haller2017-10-311-18/+13
| | | | | | Coverity detects that the "if (blob)" condition must always be true. Reorder the code, to avoid the warning. It's a bit clearer this way anyway.
* ovs: add backward compatibility wrapper for json_object_foreach() macroThomas Haller2017-10-311-0/+8
|
* policy: move blocking autoconnect from NMDeviceModem to NMPolicyThomas Haller2017-10-312-25/+23
| | | | | | | | | | Only NMPolicy should be concerned with handling autoconnect, and blocking it. Move the code. Note that there is a slight possible change in behavior, as the order of when the connection is blocked changes, based on the different times when the device changed signal gets executed. But that shouldn't be a problem.
* policy: inline can_autoconnect check in auto_activate_device()Thomas Haller2017-10-311-27/+15
|
* policy: move nm_settings_connection_can_autoconnect() to policyThomas Haller2017-10-313-27/+30
| | | | Step by step, we move all tracking of autoconnect to NMPolicy.
* device: handle authentication retries using 802-1x.auth-retries settingThomas Haller2017-10-316-54/+86
| | | | | | | | | | | | | | | | | | | | Since commit 4a6fd0e83ec0d83547b1f3a1a916f85e9f450d8c (device: honor the connection.autoconnect-retries for 802.1X) and the related bug bgo#723084, we reuse the autoconnect-retries setting to control the retry count for requesting passwords. I think that is wrong. These are two different settings, we should not reuse the autoconnect retry counter while the device is still active. For example, the user might wish to set autoconnect-retries to infinity (zero). In that case, we would retry indefinitly to request a password. That could be problematic, if there is a different issue with the connection, that makes it appear tha the password is wrong. A full re-activation might succeed, but we would never stop retrying to authenticate. Instead, we should have two different settings for retrying to authenticate and to autoconnect. This is a change in behavior compared to 1.8.
* libnm,cli,ifcfg-rh: add NMSetting8021x:auth-retries propertyThomas Haller2017-10-312-7/+10
|
View Lorry Controller Status