On 02/19/2013 11:23 AM, Dan Williams wrote: > On Tue, 2013-02-19 at 09:53 -0500, Hans-Christoph Steiner wrote: >> >> On 02/18/2013 11:34 PM, Dan Williams wrote: >>> On Mon, 2013-02-18 at 22:53 -0500, Hans-Christoph Steiner wrote: >>>> On 02/18/2013 10:44 PM, Dan Williams wrote: >>>>> On Mon, 2013-02-18 at 22:27 -0500, Hans-Christoph Steiner wrote: >>>>>> I have a hard-coded adhoc network setup with a fixed ssid, channel, >>>>>> bssid, and >>>>>> IPv4 address. This profile works fine on Ubuntu/Precise (network-manager >>>>>> v0.9.4.0-0ubuntu4) but fails on Ubuntu/quantal (network-manager >>>>>> v0.9.6.0-0ubuntu7) . On 0.9.6, it says its setting all those settings, >>>>>> but >>>>>> then actually tries on channel 1 instead, and it dynamically generates a >>>>>> BSSID >>>>>> rather than using the one in the config file that it said it was going to >>>>>> load. Attached is the NM connection file and the log from syslog. >>>>> >>>>> So check your system logs >>>>> (/var/log/messages, /var/log/NetworkManager, /var/log/daemon.log, etc) >>>>> and see what NM is sending to the supplicant. You'll see something like >>>>> this: >>>>> >>>>> Config: added 'SSID' value 'foobar' >>>> >>>> The log was attached, but here's the relevant snippet: >>>> >>>> Config: added 'ssid' value 'commotionwireless.net' >>>> Config: added 'mode' value '1' >>>> Config: added 'frequency' value '2432' >>>> Config: added 'bssid' value '02:ca:ff:ee:ba:be' >>>> >>>> >>>>> That'll tell you whether the problem is NM or the supplicant/kernel. >>>>> You should see both the channel you gave NM, the SSID, the BSSID, and >>>>> "mode 2" being sent to the supplicant. You may not know, but the >>>>> supplicant and kernel drivers have great leeway in doing what they want >>>>> with BSSID. Also beware that some newer drivers simply don't support >>>>> AdHoc mode (bcma for newer Broadcom cards, newest Intel devices). >>>> >>>> >>>> Yeah, it seems to be a driver/wifi issue, I've been wrestling with >>>> iwconfig as >>>> well, and failing. Its so lame that they don't support adhoc... >>>> >>>> The driver is called 'wl' and is a binary blob. It was also complaining >>>> in dmesg: >>>> >>>> [91534.974363] ERROR @wl_cfg80211_scan : WLC_SCAN error (-22) >>>> [93584.080241] ERROR @wl_notify_scan_status : eth0 Scan_results error (-22) >>>> [94402.076204] ERROR @wl_notify_scan_status : eth0 Scan_results error (-22) >>>> [95361.265390] ERROR @wl_cfg80211_scan : WLC_SCAN error (-22) >>>> [95994.270295] ERROR @wl_cfg80211_join_ibss : Invalid bssid >>>> [96015.656825] IPv4 over IPv4 tunneling driver >>>> [96020.714712] device eth0 entered promiscuous mode >>>> [96248.035028] ERROR @wl_cfg80211_join_ibss : Invalid bssid >>>> >>>> Guess I'll just write that little old netbook for this stuff. Any ideas >>>> how >>>> common this situation is? >>> >>> Haha. Ok, good luck with wl.o :) Since it's binary and proprietary, >>> there's not much we can do with it, nor can any of the bugs be fixed. >>> You could see if b43 works for your card. If not, you're stuck with >>> either wl.o or bmca, and we already know bcma doesn't support AdHoc. So >>> you may need to get another wifi card... >>> >>> Dan >>> >> >> Oops, I forgot the 'off' as in "write off that little old netbook". Has >> anyone found a reliable way to detect whether a driver/chip does not support >> adhoc? It would be nice to offer feedback to cut down on support requests >> like mine :) > > This is not possible with WEXT, but is possible with cfg80211. Run "iw > phy phy0 info" and see if IBSS is one of the reported modes. We just > pushed a patch to NetworkManager that looks at this property and will > fail a connection request very early if the driver doesn't support > adhoc. > > Dan
Sounds good. As for this lame driver/chipset, it does "support" adhoc, provided you wrestle with it enough. So 'iw phy phy0 info' duly reports IBSS support... .hc _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
