After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743209 - [PATCH] platform: rework link type detection for better fallback
[PATCH] platform: rework link type detection for better fallback
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks: nm-review
 
 
Reported: 2015-01-19 21:42 UTC by Dan Williams
Modified: 2015-05-01 20:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-platform-rework-link-type-detection-for-better-fallb.patch (7.95 KB, patch)
2015-01-19 21:43 UTC, Dan Williams
reviewed Details | Review
0002-platform-detect-openvswitch-interfaces-more-quickly-.patch (2.27 KB, patch)
2015-01-19 21:50 UTC, Dan Williams
reviewed Details | Review

Description Dan Williams 2015-01-19 21:42:53 UTC
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 udev's 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 (including udev) if the type is NULL *or* unrecognized.
    Make that happen and clean things up to use a table instead of
Comment 1 Dan Williams 2015-01-19 21:43:48 UTC
Created attachment 294926 [details] [review]
0001-platform-rework-link-type-detection-for-better-fallb.patch
Comment 2 Dan Williams 2015-01-19 21:46:48 UTC
Another instance of this is openvswitch, which for 3.17+ now reports a link type of 'openvswitch'.  But NM also depends on rtnl_link_get_type() being NULL for OVS devices, so that it continues on to check ethtool.  There is overall effect though, since OVS devices are still NMDeviceGeneric.
Comment 3 Dan Williams 2015-01-19 21:50:47 UTC
Created attachment 294927 [details] [review]
0002-platform-detect-openvswitch-interfaces-more-quickly-.patch
Comment 4 Dan Winship 2015-01-19 22:08:00 UTC
Comment on attachment 294926 [details] [review]
0001-platform-rework-link-type-detection-for-better-fallb.patch

>-	if (arptype == ARPHRD_ETHER)
>+	/* Standard wired ethernet interfaces don't report an rtnl_link_type

Is that always going to be a safe assumption?

> link_extract_type (NMPlatform *platform, struct rtnl_link *rtnllink, const char **out_name)

if we're going to rewrite this stuff anyway it might be nice to fix the FIXME in link_is_software() (which ought to be calling link_extract_type(), but can't because for tun/tap, link_extract_type() calls nm_platform_tun_get_properties(), which calls link_get(), which calls link_is_announceable(), which calls link_is_software()).

(The fix there might be to stop distinguishing tun and tap at the NMPlatformLinkType level, but still distinguish them at the NMDeviceTun level.)
Comment 5 Dan Winship 2015-01-19 22:09:10 UTC
Comment on attachment 294927 [details] [review]
0002-platform-detect-openvswitch-interfaces-more-quickly-.patch

>-	{ "dummy",  NM_LINK_TYPE_DUMMY },
>+	{ "dummy",       NM_LINK_TYPE_DUMMY },

just use the wider column width in the original patch :)
Comment 6 Dan Williams 2015-04-14 22:20:58 UTC
Rebased and pushed to dcbw/bgo747628-platform-udev-excise
Comment 7 Dan Williams 2015-05-01 20:30:39 UTC
Merged to master as part of dcbw/bgo747628-platform-udev-excise

2d527b30ffb57e458f8880e8cf4f5801d648ffeb