On Fri, 2009-08-14 at 11:58 +0800, Zhu Yi wrote: > The device notifies both when it begins to roam and after the new > association is made. Yes, I think I missed the cfg80211_roamed call for > the real roam event. But there is still a reassociation path that the > above situation could happen (__cfg80211_connect_result is called while > in CFG80211_SME_CONNECTED state). Or do you think we should suppress > reassoc event from driver? Would that be after a disconnect event? I think that after a DISCONNECTED event the device should go to sleep completely and wait for userspace instructions. Otherwise we end up having a weird situation _again_ where userspace has no idea what the device is doing. I suppose if the device just keeps trying you just have to tell it to stop after a bit if it doesn't find a new connections. Otherwise, if you're roaming, you still get a disconnect/reassoc or something like that? Those together should form a ROAMED event. > Actually, the code in __cfg80211_connect_result() has already handled > the (wdev->sme_state == CFG80211_SME_CONNECTED) case. The problem is > wdev->current_bss is set to NULL but leaves wdev->sme_state still as > CFG80211_SME_CONNECTED. So I think the patch is still valid, but needs a > better description. I don't think I understand? Why would you ever have a connect_result() while already connected? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
