GNOME Bugzilla – Bug 763388
RTL8191SU usb wifi not showing in nmcli dev list (includes git bisect)
Last modified: 2016-04-11 19:22:07 UTC
What triggers the bug: Insert RTL8191SU USB wifi device run "nmcli dev list" Expected result: see wlan0 device on list What happens: no wlan0 device on list (but the device still works fine without networkmanager) git bisect isolates commit 751a37bf433eb79653b6d498eea1ab01047dfd27 If the USB device is inserted when a "good" version of n-m is running, and then a "bad" version of n-m is installed/started, the device continues to work properly My guess it that this device is (for some reason) finding itself in the "NM_802_11_MODE_UNKNOWN" state, triggering a premature exit from nm-wifi-factory.c:create_device . I can test patches. See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817115
Hi Antonio, my guess is that your device is managed through wext and starts in "Auto" mode. Can you perform this test, please? Stop network manager, move your device in Managed/Infrastructure mode (also AdHoc would be fine), and then restart network manager and see if it is managed by NM. Thanks!
Created attachment 323602 [details] [review] Auto mode == Managed mode You can also try if this tentative patch solves
Hello Francesco, It is a wext device, and it does start in Auto mode. Your patch resolves this bug when applied on top of git master. Thank you!
Thanks for testing and reporting, Antonio. Well, in the hurry I put the code on the wrong line making AUTO==AP_MODE instead of AUTO==INFRASTRUCTURE as wanted (and as commented): attaching the correct patch. Maybe we will deal with this with a more elaborate patch on master in a while.
Created attachment 323634 [details] [review] AUTO == INFRASTRUCTURE
I've rebuilt with the second patch, and it also works. I'll point out that, even with the original patch, the device wound up in Mode:Managed (and not Master---I did not trace through why exactly that happened). With the new patch, it stays in Mode:Auto until "nmcli rad wifi on" is called. Since n-m seems to always put the device into a specific mode (and doesn't seem to use mode:auto), there may not even be any value in supporting mode:auto beyond simply initializing the device.
The issue here is that we skip the management of devices which are not configured in a mode supported by NM (AP, AdHoc and Infrastructure). I think the right way is to skip management of devices configured in particular modes that gives hint to not disrupt: monitor and mesh (any other?). So, to be more conservative.
Pushed my candidate patch on branch: fg/WiFi_wext-bgo763388
Well that's a creative interpretation of the WEXT spec by the driver. As far as I recall IW_MODE_AUTO was never supposed to be used as a driver-reported value, but only for clients telling the device to do whatever it wanted to do. eg, the driver would receive IW_MODE_AUTO and then set either INFRA, ADHOC, or MASTER depending on some other mechanism. Then it would report it's actual mode (INFRA, ADHOC, or MASTER) to userspace. But that's WEXT for you, highly under-specified. Anyway, review... NM_802_11_MODE_UNMANAGED - we can't add new enums between existing ones without breaking stuff. This enum is API (both C and D-Bus). I'd just use MODE_UNKNOWN here instead; do we really need a new mode? If the mode is unknown NM can't control it anyway since something is wrong or unhandled. NM should probably just map IW_MODE_AUTO to IW_MODE_INFRA I guess; it's a hack but WEXT doesn't help us here at all.
(In reply to Dan Williams from comment #9) > [...] > As far as I recall IW_MODE_AUTO was never supposed to be used as a > driver-reported value, but only for clients telling the device to do > whatever it wanted to do. eg, the driver would receive IW_MODE_AUTO and > then set either INFRA, ADHOC, or MASTER depending on some other mechanism. > Then it would report it's actual mode (INFRA, ADHOC, or MASTER) to > userspace. Thanks, I did not know this. > NM_802_11_MODE_UNMANAGED - we can't add new enums between existing ones > without breaking stuff. This enum is API (both C and D-Bus). I'd just use > MODE_UNKNOWN here instead; do we really need a new mode? If the mode is > unknown NM can't control it anyway since something is wrong or unhandled. > NM should probably just map IW_MODE_AUTO to IW_MODE_INFRA I guess; it's a > hack but WEXT doesn't help us here at all. I was afraid adding a new NM mode would break something... and that happened indeed. :-( My first thought was to be more conservative, and just map known modes that would give us an hint the device should not be taken under control (as monitor mode) and let NM take over other modes to allow it to reconfigure the device in a supported mode (also if I was not sure if this would have worked)... Moreover, thinking it a while, I cannot imagine any case that could leverage this fix other than this (WEXT driver reporting IW_MODE_AUTO). So, going to change the patch to the WEXT auto-mode hack, thanks.
Created attachment 323689 [details] [review] WEXT hack patch (aligned also fg/WiFi_wext-bgo763388 branch to this patch)
merged: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0f6febc6fbeafde62e6e0a8c12f57204d94166f
*** Bug 764877 has been marked as a duplicate of this bug. ***