On Wed, 2009-08-19 at 20:30 +0100, Dave wrote:
> > Hmm. What if the bssid isn't set? Then the card might select a different
> > BSS than the one we have on the scan list.
>
> That's correct. For the Agere driver that's also true when bssid is set
> - we can't specify which AP the firmware connects to.
Ok. We may want a feature flag for the latter case so we know what's
going on, and reject a BSSID setting.
> >> + } else {
> >> + cfg80211_put_bss(bss);
> >
> >> err = rdev->ops->connect(&rdev->wiphy, dev, connect);
> >
> > And it's all racy too -- by the time the driver calls connect_result(),
> > the BSS might have expired after it was found here now.
>
> Agreed, but with a 15s expiry period I wouldn't expect this to be a
> problem in practice.
Well, the user could scan, take 12 seconds to pick out the AP manually,
enter the paramters in another 2.5 seconds, and then it would already
happen, I think?
> > I don't think this is really feasible to implement in cfg80211.
>
> cfg80211 seemed like the appropriate place because it avoids different
> (fullmac) drivers having to re-implement this.
True.
> > Couldn't
> > the driver do a probe to the BSS that the device selected, and report
> > that before the connect result?
>
> Yes, that's possible. If we went this way it would make sense to encode
> this in the interface by changing the cfg80211_connect_result prototype to:
>
> void cfg80211_connect_result(struct net_device *dev,
> const struct bss *bss,
> const u8 *req_ie, size_t req_ie_len,
> const u8 *resp_ie, size_t resp_ie_len,
> u16 status, gfp_t gfp);
>
> So on connecting:
>
> * the driver has to call cfg80211_get_bss() to get the bss pointer.
>
> * if it is not available, scan/probe to get the information, call
> cfg80211_inform_bss(), and then use the returned pointer in the
> cfg80211_connect_result call.
>
> This means the driver may have to hold onto the IE info to use after the
> scan returns.
Indeed, that would work, although it seems somewhat pointless to pass
around the BSS pointer and require the driver to do the lookup, but it
nicely avoids any races that we have even now.
> Another alternative is for cfg80211_connect_result to trigger the scan
> if it doesn't have the bss, and only complete the connect when the scan
> returns. I think I like the sound of this best.
Good option too, though then it would be useful to pass the channel
pointer if available to scan only on that channel. Of course, if it
still can't be found things are really amiss and we should probably
disconnect and send a failed event to userspace.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
