Re: [ipw3945-devel] forcing 802.11a association

[Dan Williams <dcbw redhat com>]

On Tue, 2007-06-26 at 08:41 -0700, James Ketrenos wrote:
> dragoran wrote:
> > Derek Atkins wrote:
> >> Dan Williams <dcbw redhat com> writes:
> >>
> >>   
> >>>> Like I said, "the BSSID is the same on both (a) and (b/g)", so, yes,
> >>>> my AP (a D-Link) has the same BSSID/MAC on both bands.  I do not
> >>>> believe there is any way for me to change this.  In fact, it uses
> >>>> the same BSSID/MAC on ALL three "interfaces" (802.3, 802.11a, and 802.11b/g)
> >>>>       
> >>> Whee.  So drivers internally now have to differentiate a specific access
> >>> point based on the (band, BSSID, SSID) tuple, which I'm pretty sure not
> >>> many do.
> >>>     
> >> Um, all the drivers have ALWAYS done this.  The iwl3945 is the first
> >> driver NOT to differentiate them!  The madwifi and the ipw3945 drivers
> >> certain work "correctly" in my situation.
> >>
> >>   
> > is this a known bug (feature?) in the iwlwifi drivers / ratescale alg ?
> 
> Sounds like a gap in mac80211's ability for userspace to specify band 
> priority for association.  The drivers just tune to a band/channel and
> send frames; they no longer control which AP is selected.  With ipw3945,
> I believe if all things were equal, priority was given to the 2.4GHz 
> band.
> 
> I believe mac80211 honors the userspace channel selection as part of its
> AP selection criteria so userspace could pick the band by picking the 
> channel vs. the actual band mode.
> 
> Or am I misunderstanding the question?

No, I think you've got it.  Right now NM doesn't push a channel down to
the wpa_supplicant, which in turn doesn't push that channel down to the
driver, so it's left up to the driver what particular band to use for an
association with a particular BSSID, if that BSSID happens to exist on
both the A and B/G bands.

If NM _did_ push a channel down to wpa_supplicant, we'd have to include
roaming functionality in NetworkManager to push new channels/BSSIDs to
wpa_supplicant (and therefore the driver) as NM found new APs in the
scan results.  That's because right now, setting an explicit channel
causes the card to lock to that channel and not change until a '0'
channel is set or until a new explicit channel is sent.

Dan