GNOME Bugzilla – Bug 692869
Starting a wifi hotspot fails silently if hardware does not support Ad-Hoc mode
Last modified: 2013-02-11 17:40:52 UTC
NM does not seem to check for Ad-Hoc support and does not warn the user if support is not there before starting a hotspot. According to the UI, the hotspot is on when it actually isn't. Checking for the availability of Ad-Hoc mode shouldn't be too difficult, as it is listed by e.g. "iw list". NM should disable the hotspot option and tell the user that the hardware does not support Ad-Hoc mode. I know that the long-term plan is to support managed mode, but the current situation is a bug, in my opinion. I'm running 02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) NetworkManager-0.9.7.0-12.git20121004.fc18.x86_64 kernel-3.7.4-204.fc18.x86_64 and the Gnome Shell UI on Fedora 18. "iw list" says that I only have suppport for managed and monitor modes.
Created attachment 234916 [details] [review] core: add NM_WIFI_DEVICE_CAP_ADHOC here's a start... not tested yet. I couldn't figure out how to detect Ad-Hoc support via wext, so wifi-utils-wext just always claims it's supported... do we care? The "fails silently" part suggests a failure of communication between NM and wpa_supplicant I guess, but I'm not sure where... It seems like we should fix that as well though.
btw, do you get any errors in /var/log/messages when you try to create the hot spot?
Created attachment 235002 [details] Syslog dump upon starting hotsop
I attached a part of my syslog that appears when I start the hotspot from the graphical NM user interface. NM seems to know that starting the device in Ad-Hoc mode failed, but this is not shown in any obvious way in the user interface. (I'm on Fedora 18.)
(In reply to comment #4) > NM seems to know that starting the device in > Ad-Hoc mode failed, but this is not shown in any obvious way in the user > interface. (I'm on Fedora 18.) Well... it times out after 25 seconds, but it doesn't seem to be getting any feedback from wpa_supplicant before then saying that things failed. Oh well. The control-center should be showing a spinner during that time, and flip the switch back to OFF after that, but that's a control-center bug (now bug 693024).
brcmsmac seems to be pretty braindead here: hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION); and this is actually the first driver we've had that doesn't support adhoc mode. I know the hardware supports it, because b43 supports adhoc for the 4313 hardware, but brcmsmac doesn't appear to. So yeah, we probably do need an ADHOC capability, and the posted patch looks good. And no, there's literally no way with WEXT to determine whether the device supports adhoc or not, so we have to assume that it does.
Review of attachment 234916 [details] [review]: Looks good.
Attachment 234916 [details] pushed as fc700e9 - core: add NM_WIFI_DEVICE_CAP_ADHOC