summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* ifcfg-rh: coverity complained about not checking stat() return valueJiří Klimeš2014-12-151-2/+4
| | | | | Error: CHECKED_RETURN (CWE-252): [#def21] NetworkManager-0.9.11.0/src/settings/plugins/ifcfg-rh/plugin.c:676: check_return: Calling "stat("/etc/hostname", &file_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.]
* device: mute coverity CHECKED_RETURN (CWE-252)Jiří Klimeš2014-12-151-5/+7
| | | | | Error: CHECKED_RETURN (CWE-252): [#def20] NetworkManager-0.9.11.0/src/devices/nm-device.c:5037: check_return: Calling "g_spawn_async" without checking return value (as is done elsewhere 12 out of 13 times).
* team: only proceed with stage2 when team device is STATE_PREPAREThomas Haller2014-12-121-3/+8
| | | | | | The team device might already be in a different state because activation failed. In this case, we don't want to proceed with stage2.
* core: better handle DHCP expiry/nak during initial lease acquisition (bgo ↵Dan Williams2014-12-124-10/+25
| | | | | | | | | | | | | | | | | | | | | | | #739482) When dhclient trieds to request a previous lease and the server NAKs that lease, dhclient emits the EXPIRE state. dhcpcd has also been known to emit the 'nak' state for the same reason. (systemd's DHCP client code does not push a NAK up to NetworkManager, but jumps to the REBOOT state instead, so it is unaffected by this issue.) NetworkManager saw the expire during IP configuration and treated that as full activation failure. The connection would be restarted, the same lease requested, and the same NAK delivered, over and over. Before a lease is acquired, there is (by definition) no lease to expire, so these events should be ignored. We do, however, still want to handle abnormal failures, which is why this patch splits the EXPIRE case from the FAIL case and handles them separately. https://bugzilla.gnome.org/show_bug.cgi?id=739482
* utils: add missing va_end macro in nm_utils_uuid_generate_from_strings()Jiří Klimeš2014-12-121-0/+1
| | | | | | | | Error: VARARGS (CWE-237): [#def19] NetworkManager-0.9.11.0/src/NetworkManagerUtils.c:1748: va_init: Initializing va_list "args". NetworkManager-0.9.11.0/src/NetworkManagerUtils.c:1758: missing_va_end: va_end was not called for "args". Fixes: 9a08d8602c8775e3fd6e203b89900ba579bcce9b
* core: fix attaching managed slaves to master devices (rh #1141266)Dan Williams2014-12-111-3/+4
| | | | | | | | | | | | | | | | | | | Broken by 25387cd1ffc4b3135a13e9222c0b0e5dea506c80 When an activation request comes in via D-Bus for a slave, the slave device's priv->master is set in stage1 in master_ready_cb(). Then nm_device_bring_up() is called on the slave, which triggers link_changed_cb() and device_link_changed(). That then executes this code: if (priv->master) nm_device_enslave_slave (priv->master, self, NULL); which enslaves the slave, but due to the NULL will not configure the slave. This code was only meant to be run for externally triggered master/slave changes.
* core: fix warning when releasing slaves on exit (rh #1169936)Dan Williams2014-12-111-1/+1
| | | | | | | | | | | | NetworkManager[30304]: <info> (virbr0): bridge port virbr0-nic was detached NetworkManager[30304]: (devices/nm-device.c:962):nm_device_release_one_slave: runtime check failed: (reason == NM_DEVICE_STATE_REASON_NONE) NetworkManager[30304]: <info> (virbr0-nic): released from master virbr0 If the slave is removed, then the master is already cleaned up so NM doesn't need to do anything. 5dd48f fixed that but forgot to update the !configure case, causing the warning but no other problems. Fixes: 5dd48f7527c67b399ac144f594e035216771d61c
* core: clean up half-done IP operations when re-entering NEED_AUTH state (bgo ↵Dan Williams2014-12-111-12/+27
| | | | | | | | | | | #741342) When the device decides it needs re-auth during IP config and returns to the NEED_AUTH state, make sure we clean up any half-done IP operations since they will be re-started after auth is completed and the IP_CONFIG state is re-entered. https://bugzilla.gnome.org/show_bug.cgi?id=741342
* platform: Fix build with LIBNL_INET6_ADDR_GEN_MODELubomir Rintel2014-12-111-0/+3
| | | | | | | | | platform/nm-linux-platform.c: In function 'setup': platform/nm-linux-platform.c:4364:2: error: 'object' undeclared (first use in this function) object = nl_cache_get_first (priv->link_cache); ^ Fixes 2b8060b9b36fe8f540b38c085600f3771d4ac6b4
* device: assume connections for device with slaveslr/bridge-rh1141266Lubomir Rintel2014-12-111-3/+5
| | | | | | | If a bridge/team/bond has slaves, assume it's connected. Recheck as devices appear. https://bugzilla.redhat.com/show_bug.cgi?id=1141266
* device: set the master on device additionLubomir Rintel2014-12-113-18/+50
| | | | | Otherwise we won't notice the device is a slave on NM startup until someone changes the link or tries to activate the device.
* device: release and enslave an interface if its master changedLubomir Rintel2014-12-111-2/+3
| | | | | | | In case of an atomic master change, we'd not notice that the master changed: ip link set dummy0 master bridge0 ip link set dummy0 master bridge1
* Revert "platform: increase NL buffer for systems with lots of interfaces (rh ↵Lubomir Rintel2014-12-111-7/+0
| | | | | | | | | | #1141256)" This reverts commit efd09845c41e08469d6f6bffa23bd90b6bd06e85. It turns out that the socket space might not be the only buffer that may get too full. 128K ought to be enough for it and we should resynchronize with the kernel now if needed.
* platform: resynchronize with kernel when we're out of buffer spaceLubomir Rintel2014-12-111-10/+84
| | | | | | | | | | | | | Kernel can return ENOBUFS in variety of reasons. If that happens, we know we've lost events and should pick up kernel state. Simple reproducer that triggers an ENOBUFS condition no matter how big our netlink socket buffer is: ip link add bridge0 type bridge for i in seq $(0 1023); do ip link add dummy$i type dummy; \ ip link set dummy$i master bridge0; done ip link del bridge0
* platform: refactor the object comparison logic into a separate functionLubomir Rintel2014-12-111-18/+30
| | | | One from libnl is not good enough (see comment).
* platform: ensure all objects in link cache are of AF_UNSPEC familyLubomir Rintel2014-12-111-1/+37
| | | | | | | | | | | | | | | | | | | | We assume that in nm_nl_cache_search() and correctly set that in get_kernel_object(), but we rtnl_link_alloc_cache() can initialize the cache with devices of other families. The consequence is that we don't notify when the bridge changes to IFF_UP as we fail to match and remove the old downed object from the cache: nm_device_bring_up(): [0xf506c0] (bridge0): bringing up device. nm_platform_link_set_up(): link: setting up 'bridge0' (12) link_change_flags(): link: change 12: flags set 'up' (1) get_kernel_object(): get_kernel_object for link: bridge0 (12, family 7) log_link(): signal: link added: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0' get_kernel_object(): get_kernel_object for link: bridge0 (12, family 7) log_link(): signal: link changed: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0' log_link(): signal: link changed: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0' (bridge0): device not up after timeout! (bridge0): preparing device
* device: don't fail activation when IP config is unavailable and unneededlr/assumed-activation-rh1141264Lubomir Rintel2014-12-111-15/+40
| | | | | | | | If we didn't start IPv4 and IPv6, but they're allowed to fail, progress the activation without failing it. Also, progress assumed connections to check-ip with whatever configuration that is available. https://bugzilla.redhat.com/show_bug.cgi?id=1141264
* device: don't disconnect assumed connectionsLubomir Rintel2014-12-111-0/+8
| | | | | | Transition them to activated status when they fail. https://bugzilla.redhat.com/show_bug.cgi?id=1141264
* device: turn nm_d_ip_config_should_fail to get_ip_config_may_failLubomir Rintel2014-12-112-16/+15
| | | | | Has a cleaner semantics and will be useful later on. Also, make it static -- it's not used outside nm-device.c.
* tests: fix setting MAC address in testsJiří Klimeš2014-12-111-3/+1
| | | | | | | MAC address properties are strings now. The change has been done by commit 3a54d050985d6ef2067b025571910a8ccd3cbd57. But this place was not updated. Reported by lrintel in copr.
* core: don't wipe out VPN secrets if we're changing the connectionLubomir Rintel2014-12-111-0/+6
| | | | | The VPN secret properties are hashes and thus the default property value does not work with them.
* agent-manager: don't ever fail the secrets requests from GetSecrets()Lubomir Rintel2014-12-113-3/+11
| | | | | | VPN connections always return true for nm_connection_need_secrets(), but the documented behavior of GetSecrets() is just to return any secrets we have (otherwise nmcli c --show-secrets would not be useful for VPN connections).
* platform: avoid conflicts when reinstalling the device-routeThomas Haller2014-12-114-33/+102
| | | | | | | | | | | | | | | | | | | Since f32075d2fc11252e5661166b2f46c18c017929e9, we remove the kernel added IPv4 device route, and re-add it with appropriate metric. This could potentially replace existing, conflicting routes. Be more careful and only take any action when we don't have a conflicting route and when we add the address for the first time. The motivation for this was libreswan which might install a VPN route for a subnet that we also have configured on an interface. But the route conflict could happen easily for other reasons, for example if you configure a conflicting route manually. Don't replace the device route if we have any indication that a conflict could arise. https://bugzilla.gnome.org/show_bug.cgi?id=723178
* device: add logging macro _LOGT()Thomas Haller2014-12-091-0/+1
|
* core: implement nm_utils_find_helper() based on nm_utils_file_search_in_paths()Thomas Haller2014-12-051-47/+14
| | | | | | | This also changes behavior in that we now only find files that are executable. https://bugzilla.gnome.org/show_bug.cgi?id=740783
* utils: fix converting milliseconds to microsecondsJiří Klimeš2014-12-051-2/+13
| | | | | | Coverity: Defect type: CONSTANT_EXPRESSION_RESULT /src/NetworkManagerUtils.c:726: result_independent_of_operands: "18446744073709551615UL /* 9223372036854775807L * 2UL + 1UL */ < (gulong)sleep_duration_msec * 1000UL" is always false regardless of the values of its operands. This occurs as the logical first operand of '?:'.
* bluetooth: the code cannot be reachedJiří Klimeš2014-12-051-3/+2
| | | | | | | | because either GSM or CDMA is present. It is checked just above. Coverity: Defect type: DEADCODE src/devices/bluetooth/nm-device-bt.c:312: dead_error_line: Execution cannot reach this statement: "fallback_prefix = dcgettext...".
* platform: ignore nm_platform_ip4_route_add/delete return valueJiří Klimeš2014-12-051-3/+5
| | | | | Coverity: Defect type: CHECKED_RETURN
* utils: initialize timespec structureJiří Klimeš2014-12-051-4/+4
| | | | | | | | | Coverity: Defect type: UNINIT src/NetworkManagerUtils.c:1906: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get". src/NetworkManagerUtils.c:1879: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get". src/NetworkManagerUtils.c:1852: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get". src/NetworkManagerUtils.c:1825: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
* util: fix _log_connection_sort_names_fcn()Jiří Klimeš2014-12-051-2/+2
| | | | | | Coverity: Defect type: CONSTANT_EXPRESSION_RESULT src/NetworkManagerUtils.c:1978: same_on_both_sides: "(v1->diff_result & NM_SETTING_DIFF_RESULT_IN_B) != (v1->diff_result & NM_SETTING_DIFF_RESULT_IN_B)" is always false regardless of the values of its operands because those operands are identical. This occurs as the logical operand of if.
* settings: change algorithm for UUID generation based on stringsThomas Haller2014-12-042-8/+9
| | | | | | | | | | | | | In several cases, connection uuids are generated based on some strings. Change the algorithm, to prefix the hashed identifier differently for each setting type. This makes collisions very unlikely. Also, change the algorithm, to create proper Variant3 UUIDs. This is a behavioral change, but it only affects code places that were added since nm-0-9-10 and were not yet part of a stable release.
* core: add nm_utils_uuid_generate_from_strings()Thomas Haller2014-12-043-0/+95
| | | | | Add function to create variant3 UUIDs based on a set of concatenated strings.
* libnm: add a type argument to nm_utils_uuid_generate_from_string()Thomas Haller2014-12-045-6/+6
| | | | | | | | | | | | | There are different types (variants) of UUIDs defined. Especially variants 3 and 5 are name based variants (rfc4122). The way we create our UUIDs in nm_utils_uuid_generate_from_string() however does not create them according to RFC and does not set the flags to indicate the variant. Modify the signature of nm_utils_uuid_generate_from_string() to accept a "uuid_type" argument, so that we later can add other algorithms without breaking API.
* libnm: accept additional length argument in nm_utils_uuid_generate_from_string()Thomas Haller2014-12-045-6/+6
| | | | | This makes the function also useful for non C-strings, non UTF-8-strings, and generic blobs.
* core: don't bounce disable_ipv6 when assuming connections (rh #1170530)Jiří Klimeš2014-12-041-1/+1
| | | | | | | | | | | Don't call set_nm_ipv6ll(self, TRUE) on any assumed connection since it would bounce disable_ipv6, which would break IPv6 connectivity. That is critical, for example, for installations via NFS. Fixes: d37b7bed305dbed7b5351038850ef6bbb7ed9c59 https://bugzilla.redhat.com/show_bug.cgi?id=1170530 Related: https://bugzilla.redhat.com/show_bug.cgi?id=1052157
* libnm: remove nm_utils_init() from the public APIDan Winship2014-12-042-7/+0
| | | | | Remove nm_utils_init() from the public API, and just do it as a constructor instead.
* core: fix leak of generated connection if device is activeDan Williams2014-12-031-5/+4
| | | | | Don't generate (and add to settings) a connection if we aren't going to use it anyway.
* devices: don't release slaves on exit (rh #1169936)Dan Winship2014-12-031-1/+1
| | | | | | | | | | | | nm_device_removed() calls nm_device_release_one_slave() in order to fix up NetworkManager's master/slave bookkeeping, but we don't want to tell the kernel to actually unslave the device, since that would happen automatically anyway if the device was really removed, and shouldn't happen if the device is just being removed from NM's device list. (In particular, don't remove all libvirt-created virtual network devices from virbr0 when NetworkManager exits.)
* ifcfg-rh: don't include nm-utils-private.h outside of libnm-core/Thomas Haller2014-12-031-1/+0
|
* device: Deal with links that vanish during initializationLubomir Rintel2014-12-023-4/+9
| | | | | | | | | | | | | | | | | | | | | nm_device_get_hw_address() may return NULL and nm_platform_link_get_type may return NM_LINK_TYPE_NONE. While it might be a good idea to check for such cases at the init time it seems easier to just ignore it and prevent blowing up in subsequent deactivation. A quick test case: # while :; do ip link add moo0 type veth peer moo1; ip link del moo0 ; done Yields: NetworkManager:ERROR:devices/nm-device-ethernet.c:268:constructor: assertion failed: (link_type == NM_LINK_TYPE_ETHERNET || link_type == NM_LINK_TYPE_VETH) nm_device_set_hw_addr: assertion 'addr != NULL' failed https://bugzilla.gnome.org/show_bug.cgi?id=740992
* iface-helper: disambiguate route priority for IPv4 and IPv6Thomas Haller2014-12-012-16/+20
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=740780
* core: rename NM_PLATFORM_ROUTE_METRIC_DEFAULT to ↵Thomas Haller2014-12-013-6/+12
| | | | | | | | | | | NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP6 For IPv4, iproute for example defaults to a metric of 0. Hence, the name NM_PLATFORM_ROUTE_METRIC_DEFAULT was misleading. Also add a NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP4 define for completeness. https://bugzilla.gnome.org/show_bug.cgi?id=740780
* keyfile: assert in writer to have valid connection idThomas Haller2014-11-281-5/+1
| | | | | Few lines above we already verify the connection. We must have an @id.
* devices: NM_SETTING_WIRED_S390_SUBCHANNELS is now G_TYPE_STRV (rh #1168764)Jiří Klimeš2014-11-281-9/+8
| | | | | | | | Fixes crash on s390. The type change of the property was done in 6a4127cfa063a77e3ee886a999441c71f6a0e11c, but we forgot to update this function. https://bugzilla.redhat.com/show_bug.cgi?id=1168764
* core: adjust values for default route-metrics per device typeThomas Haller2014-11-262-21/+28
| | | | | | | | We recently changed default values for route metrics. Revise that again and increase the space between the default values. No strong reason to do this, but it seems better to have larger gaps and make use of the available range.
* vpn: don't choose route priority for VPN connections based on the parent deviceThomas Haller2014-11-261-12/+2
| | | | | | | | | | The parent device is just the device that happens to be the best device. It does not mean, that its route metric should be inherited to the VPN connection. This also makes the resulting route metric for VPN connections much more predictable: now it is either ipv4.route-metric from the connection, or it falls back to NM_VPN_ROUTE_METRIC_DEFAULT (10).
* iface-helper: make priority variable guint32Thomas Haller2014-11-251-3/+4
| | | | | | | Also read the command line argument as G_OPTION_ARG_INT64 type. Otherwise, on 32-bit integers, you could not enter any number larger then G_MAXINT32. Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: fix route metrics for subnet routesThomas Haller2014-11-257-13/+54
| | | | | | | | | | | | | | | | For IPv4 addresses, the kernel automatically adds a route when configuring an IP address. Unfortunately, there is no way to control this behavior or to set the route metric. Fix this, by adding our own route and removing the kernel provided one. Note that this adds a major change in that we no longer call nm_ip4_config_commit() for assumed devices. https://bugzilla.gnome.org/show_bug.cgi?id=723178 Signed-off-by: Thomas Haller <thaller@redhat.com>
* platform: add paramter to ip4_route_add to set src (RTA_PREFSRC)Thomas Haller2014-11-258-21/+32
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm: allow zero prefix length for NMIPRouteThomas Haller2014-11-246-3/+16
| | | | | | | | | | | | | | | | | | NMIPRoute is used by NMSettingIPConfig, but also NMIPConfig. In the former case, default routes are (still) disallowed. But in the NMIPConfig use-case, it can make sense to expose default routes as NMIPRoute instances. Relax the restriction on the NMIPRoute API to allow this future change. No code actually supports having NMIPRoute instances with prefix length zero (default routes). Up to now, all such uses would be a bug. https://bugzilla.gnome.org/show_bug.cgi?id=739969 Signed-off-by: Thomas Haller <thaller@redhat.com>
View Lorry Controller Status