On Wed, 2009-10-14 at 16:35 -0700, Luis R. Rodriguez wrote:
> Well sure, but why do we want to keep the authentication present if
> association failed? And as a matter of fact it lingers there forever.
> Is that desired behaviour?
Yes, well, the SME is supposed to clean it up or try the association
again (possibly with different parameters in the IEs, e.g. different WPA
settings). The cfg80211 SME certainly does so (it deauthenticates).
> > > +++ b/net/mac80211/mlme.c
> > > @@ -1463,11 +1463,11 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
> > > if (status_code != WLAN_STATUS_SUCCESS) {
> > > printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
> > > sdata->dev->name, status_code);
> > > list_del(&wk->list);
> > > kfree(wk);
> > > - return RX_MGMT_CFG80211_ASSOC;
> > > + return RX_MGMT_CFG80211_DEAUTH;
> >
> > I'm sure this is correct. Maybe cfg80211 doesn't react properly to
> > getting an assoc frame with non-zero status?
>
> I see, will have to take a look when I get a chance then, not now though.
> Actually can you elaborate a little on the logic here as to why
> we want to issue an association command with non-zero status to
> cfg80211 instead of just knocking off the current authentication
> and killing the BSS?
Is the above sufficient? Btw, please don't talk about "killing the BSS",
you're not talking about a BSS struct but rather one of the mlme work
structs.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
