Hi Lars,
> AP deauthentication.
> =====================
> When any of the ieee80211_rx_mgmt_deauth() or ieee80211_rx_mgmt_disassoc()
> are executed, the mac layer takes two actions.
> 1) Tells wpa_supplicant what had happened.
> 2) Start reestabliching the connaction again.
>
> The later action will stop or significantly delay the decisions/action taken
> by wpa_supplicant as a result of action 1. Normally the supplicant will
> start an AP scan.
> But the mac layer is busy with reestablishing the link and will not start
> any scan action.
Does associating actually block scanning?
> My patches simply put the mac layer in IEEE80211_DISABLED state and wait for
> the supplicant to decide.
That would break supplicant-less operation which we can't do.
> The ieee80211_rx_h_sta_process() and ieee80211_associated() are involved in
> monitors for dead AP connection. A last_rx value is set to indicate a
> working connection.
>
> The porblem is the following lines.
> if (!is_multicast_ether_addr(hdr->addr1) ||
> rx->sdata->vif.type == IEEE80211_IF_TYPE_STA) {
>
> Any package that arrives to an STA will update the last_rx value and
> prohibit a link lost action.
>
> I have noticed in my system that this function receives the following type
> of frames:
> 1) Broad cast frames from my BSS (beacons).
> 2) Data frames addressed to me ;)
> 3) Data frames from other STA addressed to other MAC addresses but using the
> same BSS.
>
> It is the case 3 that creates the problem. Another STA, closer to my BSS
> will update my last_rx value even I do not receive the BSS.
I'm pretty sure case 3 can't create a problem there since rx->sta
wouldn't be set to the AP. Can you please print out "rx->sta->addr"
after the !sta check in ieee80211_rx_h_sta_process and send me the log
indicating that we can actually get into there with sta != our own AP?
If we can that's a bug elsewhere but I doubt it.
> Timeout handling
> =================
> When any of the ieee80211_authenticate() or ieee80211_associate() function
> are executed.
> The mac silently set its state to IEEE80211_DISABLED and waits for the
> wpa_supplicant to timeout its current action.
>
> I think it would be a good idea to signal to the supplicant that the
> operation has timeout, and no further action will be taken.
> To speed up the timeout response I had squeezed the supplicant timeout.
How do you signal that? Make a wext event with the BSSID all-zeroes or
something? Sounds ok.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
