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

_______________________________________________
networkmanager-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to