summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* platform: fix root-tests after adding link detection without udevlr/nm-1-0-udev-unmanaged-fd731014Thomas Haller2015-05-285-36/+10
| | | | | | | | | | | | | | Co-Authored-By: Lubomir Rintel <lkundrak@v3.sk> Fixes: 388b7830f322b60960884328ff51f7b4df0ef3d3 (cherry picked from commit b22bf15c1d4aca4aada52debbe5f4641f5db24a4) Conflicts: src/platform/tests/test-address.c src/platform/tests/test-cleanup.c src/platform/tests/test-link.c src/platform/tests/test-route.c src/tests/test-route-manager.c
* platform: keep udev-device in udev_device_added() even if there is no ↵Thomas Haller2015-05-281-4/+4
| | | | | | | | | | | | | | | | | netlink object Throwing away the udev_device instance is wrong. There are two cases: - the udev-device appears, and the netlink object will never appear (or is already gone). In this case, keeping the udev-device is ok because we will eventually get a signal from UDev to cleanup the device instance. - the udev-device appears before the netlink object. In this case we want to keep the udev instance to have it ready. Fixes: 388b7830f322b60960884328ff51f7b4df0ef3d3 (cherry picked from commit 7572837375d6eed2833eb5144fc8f9221c57eedf)
* platform: intern driver string for NMPlatformLinkThomas Haller2015-05-283-13/+14
| | | | | | | | | | | | | | | | | Always intern string from udev_get_driver(). We use the result of udev_get_driver() for setting NMPlatformLink.driver. In all other cases, we already set that value to an interned string, which simplifies memory handling. As it was, the lifetime of that string was tied to the lifetime of the GUdevDevice. This is not a stelar solution, but we assume that the overall numbers of different drivers is limited so we don't leak large amounts of memory. (cherry picked from commit 3171b543dc30090fc50d0c74786e76062e079ed2)
* platform: refactor extraction of type-name for linkThomas Haller2015-05-286-39/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | link_extract_type() would return the NMLinkType and a @type_name string. If the type was unknown, this string was rtnl_link_get_type() (IFLA_INFO_KIND). Split up this behavior and treat those values independently. link_extract_type() now only detects the NMLinkType. Most users don't care about unknown types and can just use nm_link_type_to_string() to get a string represenation. Only nm_platform_link_get_type_name() (and NMDeviceGeneric:type_description) cared about a more descriptive type. For that, modify link_get_type_name() to return nm_link_type_to_string() if NMLinkType could be detected. As fallback, return rtnl_link_get_type(). Also, rename the field NMPlatformLink:link_type to "kind". For now this field is mostly unused. It will be used later when refactoring platform caching. (cherry picked from commit e2c742c77b7c708d6a5e6f689ff7cc91b23ab445) Conflicts: src/nm-manager.c src/platform/nm-linux-platform.c
* platform: expose nm_link_type_to_string() functionThomas Haller2015-05-282-1/+3
| | | | | | | | | | | | | | | Given the name nm_link_type_to_string(), we would not expect to find it in nm-linux-platform.c. It either should be named nm_platform_link_type_to_string() and be put in a new nm-platform-utils.c file, or it should be named nm_utils_link_type_to_string() and be put in NetworkManagerUtils.h. For now, just leave it here. (cherry picked from commit b538adf12393f67d60f7f5ec74b2a3c1b968f35b) Conflicts: src/platform/nm-platform.h
* platform: detect TUN/TAP device in link_extract_type() independently of ↵Lubomir Rintel2015-05-281-4/+10
| | | | | | | | | | | | | | | | | | | | platform cache link_extract_type() would call tun_get_properties() to determine whether the link if a TAP or TUN device. The previous implementation would receive the ifindex, and resolve the ifname via lookup in the platform cache. This means, the call on link_extract_type() will only succeed to detect the TUN/TAP properties, if the libnl object is already in the cache. Currently that is always the case and there is no problem. It is desireable, that we can resolve the link type of an object without consulting the platform cache first. (cherry picked from commit 18d611d5d2a613204e7123fda3d3f75271722df6) Conflicts: src/platform/nm-linux-platform.c
* core: remove G_GNUC_WARN_UNUSED_RESULT from ASSERT_VALID_PATH_COMPONENT()Thomas Haller2015-05-281-1/+1
| | | | | | | | ASSERT_VALID_PATH_COMPONENT() always returns the input argument -- unless it fails an assertion and terminates the program. No need to require the user to use the return value. (cherry picked from commit 63bb33b5346b431d92e413b8bc6bafc50c8ff9b7)
* core: change activation failure messages to debug levelDan Williams2015-05-281-3/+3
| | | | | | Otherwise any user with network control privileges can spam the logs. (cherry picked from commit 8a5910c25cd0102d36a9adbb7a2c831e4fa5e046)
* platform: rework link type detection for better fallback (bgo #743209)Dan Williams2015-05-283-80/+59
| | | | | | | | | | | | | | | | | | | | | | | See "Revert "wireless: Support of IFLA_INFO_KIND rtnl attribute"" http://www.spinics.net/lists/linux-wireless/msg132219.html The reverted kernel patch caused rtnl_link_get_type() to return "wlan" for WiFi devices. Since NM depends on this function returning NULL for WiFi devices so that it goes on to check the sysfs DEVTYPE attribute, the kernel patch caused WiFi devices to show up as Generic ones instead. That's wrong, and NM should be able to more easily handle changes in the kernel drivers from NULL to a more descriptive rtnl_link_get_type() return, since that's the kernel trend. What NM should be doing here is to fall back to other detection schemes if the type is NULL or unrecognized. Make that happen and clean things up to use a table instead of a giant if(strcmp()) block. https://bugzilla.gnome.org/show_bug.cgi?id=743209 (cherry picked from commit 2d527b30ffb57e458f8880e8cf4f5801d648ffeb) Conflicts: src/platform/nm-linux-platform.c
* platform: refactor link-type to string conversionDan Williams2015-05-281-36/+72
| | | | (cherry picked from commit b484b03acf66f99ef59cc688de291f07f1cc5603)
* platform: don't wait for udev before announcing linksDan Williams2015-05-288-95/+111
| | | | | | | | | (cherry picked from commit 388b7830f322b60960884328ff51f7b4df0ef3d3) Conflicts: src/nm-manager.c src/platform/nm-linux-platform.c src/platform/nm-platform.h
* core: add generic NMDevice function to recheck availabilityDan Williams2015-05-286-90/+91
| | | | | | And use it everywhere. (cherry picked from commit 3006df940ca254ed999e527a6e797fd016e7ebc9)
* platform: don't use udev for link type determinationDan Williams2015-05-283-46/+47
| | | | | | | This allows us to always announce links when the kernel advertises them, instead of waiting for udev. (cherry picked from commit 2599dadc2859262de784567384ba72ab92204d55)
* platform/trivial: move ethtool codeThomas Haller2015-05-281-79/+81
| | | | (cherry picked from commit 2bb44d91d814b6d2054e3e1d17002f58d6f273b5)
* platform/trivial: move udev_detect_link_type_from_device()Thomas Haller2015-05-281-36/+35
| | | | (cherry picked from commit dffb18cb34e616f4d10cb640e04d4970d6db74fa)
* platform: split link_type_from_udev()Thomas Haller2015-05-281-9/+10
| | | | | | | Also change link_extract_type() to accept NULL as @platform argument. (cherry picked from commit 34d82d0df19d73b30708dc4a3e9f8d91da3721c0)
* platform/trivial: move udev code closer to beginning of nm-linux-platform.cThomas Haller2015-05-281-42/+46
| | | | (cherry picked from commit d695776d484c7cbc2fdd398cf960c6521a026b1a)
* platform/trivial: remove unused argument from udev_get_driver()Thomas Haller2015-05-281-2/+2
| | | | (cherry picked from commit 7354dc4c586bbc076d2a238cb52f2d397cdb81c9)
* platform/trivial: move code around so that libnl related stuff is togetherThomas Haller2015-05-281-90/+91
| | | | | | | | Reorder some functions in nm-platform, so that we first have independent libnl wrappers/utils, then NMPlatform type definition, and then the rest. (cherry picked from commit 850af91f22a2419fecd3ff277406f790525d7ce5)
* device: turn off "unmanaged unless IFF_UP externally" for vethLubomir Rintel2015-05-281-0/+12
| | | | | | | | | | We currently don't manage a veth inside a container despite we should because it's an externally configured software interface and thus waits for IFF_UP. Given veths are prevented from being managed outside of a container by an udev rule anyway it's safe to lift the external IFF_UP requirement for them. (cherry picked from commit bcc79cc0eb1172a51a25741cf61be6ae493672fb)
* device: move the decision whether to wait for IFF_UP a virtual functionLubomir Rintel2015-05-282-6/+15
| | | | | | We'd like to override it for veths. (cherry picked from commit adb6e9afb196ffa9498e7c2708ba11fba9273377)
* bridge/bond/team: device availability shouldn't depend on IFF_UP (bgo #746918)Dan Williams2015-05-283-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | The merge of lr/udev-unmanaged-fd731014 made all devices wait until udev found them, but that makes these three device types fail activate when created by NM itself. Since their availability depended on IFF_UP, they could not be activated (eg, 'nmcli con up team0') until they were IFF_UP. But when they are created by NM, although NM knows the ifindex the platform ignores the interface until udev finds it. Thus immediately after creating the interface in _internal_activate_device() it won't be known to the platform, so the nm_device_is_available() check that controls whether the device moves to DISCONNECTED will fail. This prevents any activation and emits the message: "Connection 'foo' is not available on the device %s at this time." because the device is still in the UNAVAILABLE state. danw asked why we care about IFF_UP for these devices, and I can't remember why, and I don't think it makes sense to require now. https://bugzilla.gnome.org/show_bug.cgi?id=746918 (cherry picked from commit 568a8d1da924357125a6addd81b5f870bf31e144)
* platform: prevent warning when udev is clueless about a deviceDan Williams2015-05-281-1/+1
| | | | | | | | | | | udev doesn't know about the device yet when NM creates it internally. NetworkManager[9275]: <info> (team0): carrier is OFF NetworkManager[9275]: <info> (team0): new Team device (driver: 'team' ifindex: 16) (NetworkManager:9275): GUdev-CRITICAL **: g_udev_device_get_property: assertion 'G_UDEV_IS_DEVICE (device)' failed NetworkManager[9275]: <info> (team0): exported as /org/freedesktop/NetworkManager/Devices/5 (cherry picked from commit 8173f0f9e8045638f491e55150352576682879dd)
* Revert "core: make veth devices default-unmanaged for now"Lubomir Rintel2015-05-281-1/+0
| | | | | | | | | This reverts commit ebeaeaed4d3180c27cc059fe0ff199153fa9ec24. No need to hardwire these as unmanaged anymore, an udev rule will take care of it. (cherry picked from commit 498d45e85ff6d5ff86ba76c4e38b140cdce7d640)
* data: move OLPC MESH udev rules away from calloutsLubomir Rintel2015-05-283-7/+4
| | | | | | | | | No idea why was it there in the first place. This also fixes a bug that the rules file was conditionally included in dist depending on presence of udev dir at configure time. (cherry picked from commit ceea3c678279a81daa3f28c4e549a7e37f04188e)
* data: add udev rules to make emulated ethernet devices default unmanagedLubomir Rintel2015-05-282-0/+40
| | | | | | | | | | | There are some out-of-tree drivers that create devices masquerading as ethernets which are supposed to use their own management tools. Avoid touching them. The rules should be run after 80-net-setup-link.rules, so that the ID_NET_DRIVER is set. (cherry picked from commit 7ba30cfd265d5cde4afc96685f138cad23921138)
* platform: give the platform an opportunity to override default-unmanagedLubomir Rintel2015-05-286-1/+75
| | | | | | | | | | | | | | | | | | | | | | Some out of tree drivers add Ethernet devices that are supposed to be managed by other their tooling, e.g. VirtualBox or VMWare. Rather than hardcoding their drivers (at least VirtualBox doesn't even set a "driver" property in sysfs) or hardcoding a logic that identifies such devices let's just add a possibility to blacklist them in udev. This makes it possible for whoever who ships such a driver to ship rules that prevent NetworkManager from managing the device itself. Furthermore it makes it possible for the user with special needs leverage the flexibility of udev rules to override the defaults. In the end the user can decide to let NetworkManager manage default-unmanaged interfaces such as VEth or turn on default-unmanaged for devices on a particular bus. An udev rule for VirtualBox would look like this: SUBSYSTEM=="net", ENV{INTERFACE}=="vboxnet[0-9]*", ENV{NM_UNMANAGED}="1" (cherry picked from commit 85ee1f4a9c04cad8f2486f858efd5ca10cb09077)
* platform: don't wait for udev device initializaton if there's no udevLubomir Rintel2015-05-286-51/+43
| | | | | | | | | | | | | | | | There's no udev running in containers, it only starts if /sys is writable. If a hardware device is added to the container's namespace NM would not announce it. This also removes the software link special case -- the software links will now wait for udev initialization (in case udev is there) as well. There's no reason to treat them differently anymore. This makes it possible to use udev properties of the software links. https://bugzilla.gnome.org/show_bug.cgi?id=740526 (cherry picked from commit 4a0586955767537b7494f931ccaa93bbf59c36f9) Conflicts: src/tests/test-route-manager.c
* contrib: ensure udev rules from RPM package are appliedLubomir Rintel2015-05-281-0/+6
| | | | | | | We install udev rules and need to ensure that correct ones are in effect when the package is installed, updated or removed. (cherry picked from commit b3667afa22d01ac4834c12ea23dae182083b7971)
* Partially revert "dhcp: gracefully recover from failed DHCP BOUND state ↵Dan Williams2015-05-261-2/+2
| | | | | | | | | transitions (bgo #743700)" This reverts commit 7daf63461de4195b1626ca15f835fc7cbc56e847. Turns out the removal of the second set of [] in configure.ac causes the command to be wrong in 'configure' and the test to be incorrect.
* libnm-glib: do not access NULL GError variable (rh #1224819)Jiří Klimeš2015-05-261-4/+6
| | | | | | | | | dbus_g_proxy_call() should set GError if returning FALSE. But apparently there is a bug in dbus-glib and the error can be NULL. https://bugzilla.redhat.com/show_bug.cgi?id=1224819 (cherry picked from commit f46eb1fc2086fe0bb952da52c276a1b6ded868dc)
* vpn: don't fail if no system secrets existDan Williams2015-05-201-1/+1
| | | | | | | | | | | | | | The VPN connection requests secrets a few times; first it retrieves only system-owned secrets to see if they are sufficient (and thus doesn't need to bother the user), then it retrieves existing agent owned secrets (so the user doesn't get a popup), then finally if those aren't sufficient it asks the user interactively. But if there was some error retrieving system secrets, or if there weren't any system secrets at all, don't fail the VPN connection. Just go on and ask the user for the secrets. (cherry picked from commit 5b1cde1bfc5aa4d8e8219ee66ff637af7e62a2ec)
* systemd: fix build with toolchains not exporting CLOCK_BOOTTIMEDan Williams2015-05-191-0/+9
| | | | | | | See 123322c6d61b8db9e8e7a627c80d8d4df43a5c8d for the NM-side fix. We need this too for the systemd code. (cherry picked from commit e47eca8761e060402a05d7c0757b40455307ec90)
* connectivity: use default on missing connectivity.interval configThomas Haller2015-05-193-4/+13
| | | | | | | | | | | | | Manual page claims that a missing configuration option for connectivity interval means "300". That was not the case for a long time (never?). https://bugzilla.gnome.org/show_bug.cgi?id=723350 Based-on-patch-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com> (cherry picked from commit 652853e0d0749a12db07e34f1a3cd901020a76f8) Conflicts: src/nm-config-data.c
* config: return internal field directly in ↵Thomas Haller2015-05-191-1/+1
| | | | | | | | | nm_config_data_get_connectivity_interval() We already initialize connectivity.interval apprepriately in constructor(). No need to MAX() it again. (cherry picked from commit 5b04fde302a7264a7d361043bfcdde7855341727)
* config: minor fix in read_entire_config()Thomas Haller2015-05-191-2/+1
| | | | | | | | | Calling read_entire_config() without passing a @cli argument would always have caused an assert due to unset @o_config_main_file. That is not a real problem as that situation didn't arise. Still fix it. (cherry picked from commit ae0608eef51cad2a583e98a17e478fbb497252f5)
* dns: don't override DHCP-supplied search order with domainBeniamino Galvani2015-05-171-24/+30
| | | | | | | | | | | | | | | | | | | | NM always prepends the list of DNS domains received through DHCP to the search list in /etc/resolv.conf, overriding the DHCP-supplied DNS domain search order. This behavior is not entirely correct since it changes the search order provided by system administrators. We cannot simply avoid adding the DNS domain list to the search list because this would break some configurations that rely on the 'domain' option to deliver the search list. This patch modifies the behavior of DNS manager to: - insert the DHCP-provided 'domain' at the end of 'searches' option so that 'searches' is always preferred - ignore 'domain' if 'searches' option exists and 'domain' is a single domain https://bugzilla.gnome.org/show_bug.cgi?id=748900 (cherry picked from commit 6edc7371734315d57de020193102938846b2eb9e)
* core: merge branch 'th/reduce-info-logging-rh1212196'Thomas Haller2015-05-1317-73/+68
|\ | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1212196 (cherry picked from commit c47b9624e2d2fc9ccb09ced96c5b7e720def563)
| * device/logging: downgrade log level of "Activation: Stage x of 5" messagesThomas Haller2015-05-131-39/+27
| | | | | | | | | | | | | | | | Only downgrade the <info> levels to <debug>. Leave warnings unchanged. https://bugzilla.redhat.com/show_bug.cgi?id=1212196 (cherry picked from commit 255f30c3627c43b38720001309bf36112b91d6f5)
| * core/logging: reduce info logging messages for devicesThomas Haller2015-05-132-6/+10
| | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1212196 (cherry picked from commit b91b8a035ce4fa334513c68033df92485e73e71d)
| * device/logging: log connection UUID when activating connectionThomas Haller2015-05-131-2/+3
| | | | | | | | | | | | | | It is often hard to understand whether we activate an assumed connection. Only the UUID is unique. (cherry picked from commit 9983e4eff5b07ed217cf60785039dfeb9fbbfd19)
| * core/logging: adjust log line about loading setting pluginsThomas Haller2015-05-131-1/+1
| | | | | | | | | | | | | | We have different kinds of plugins (settings, dhcp, dns). Clearify, that we are about to load "settings" plugins. (cherry picked from commit e9b9d9b627acaf39a24514cf69bcf5a4329f8fcf)
| * core/logging: downgrade some <info> loggings to <debug>Thomas Haller2015-05-132-2/+2
| | | | | | | | | | | | | | These logging statements are compile time dependent and add little informational value. (cherry picked from commit d8e1d9b469aeeca3291acab3088193e3f7ae43b9)
| * device: expose nm_device_has_capability() functionThomas Haller2015-05-132-9/+11
| | | | | | | | (cherry picked from commit 756b756c2c4a4546a3ad69ff4f42d954701363bf)
| * device: use NMDeviceCapabilities enum for device capabilitiesThomas Haller2015-05-1313-14/+14
|/ | | | (cherry picked from commit 2117bef864c1820da337e2b491ba67f865955ec0)
* merge branch 'backport' into nm-1-0Thomas Haller2015-05-139-54/+133
|\ | | | | | | | | | | | | Backport a few bug fixes from master. Also backport the valgrind suppression file and changes to platform's 'test-common.c'.
| * platform/test: include call location in signal assertionsThomas Haller2015-05-132-21/+29
| | | | | | | | | | | | | | | | | | | | Hard to debug failures, if we don't print where the failure happens. (cherry picked from commit 500cbcba21a2602bcb172f6a5cd9b13780cd18f0) Conflicts: src/platform/tests/test-common.c
| * platform/test: make asserting signals more flexibleThomas Haller2015-05-134-29/+37
| | | | | | | | | | | | | | | | | | Support accepting more then one signal at a time. It is to be expected, that one change in platform raises several signals. Extend the assertion helpers to express that. (cherry picked from commit 050c644cce110bef4f48499498e2b6192dca7040)
| * test: fix wrong use of memcmp() in nmtst_platform_ip4_routes_equal()Thomas Haller2015-05-131-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | And nmtst_platform_ip6_routes_equal(). As already indicated by the comment, using memcmp() doesn't really work here. It worked up to now, because the NMPlatformIP4Route structure has no padding at the end. If we would have a last 'guint8' member (as we will add later), initializing an arry of routes on the stack would not clear the bytes from the padding and the comparison using memcmp() would fail. (cherry picked from commit d8d0c481b8d1ad5e9599994c5e8f8fa83657ce5c)
| * platform: fix nm_platform_link_cmp() to consider ifindexThomas Haller2015-05-131-0/+1
| | | | | | | | (cherry picked from commit f167346534f98a803a6a7fd6e274cd1d07479f18)
View Lorry Controller Status