Dan Williams <dcbw@xxxxxxxxxx> writes: >> How does the compact-wireless driver handle the case, when a >> connection of a STA to an AP gets lost? > > Right now, the lowest-common-denominator is that the driver sends a > disconnection event to userspace, and userspace handles reconnection as > it sees fit. Some drivers may attempt to reconnect to the AP > periodically until told not to. Are you talking about mac80211 drivers here? I haven't seen any mac80211 driver do that. > I personally think the driver/stack should try a few reconnections to > the AP (without sending the SIOCSIWAP disconnect event) and only if > those all fail, send the disconnect event. Actually I disagree with this, because it might slowdown roaming too much. The logic should be either in user space or in mac80211, but not in both. Now it's implemented in user space and, in my opinion, that's the best place. > But if the reconnection was successful, send the SCIOCSIWAP event > for the AP even if it matches the old AP's BSSID just so userspace > knows that something happened. wpa_supplicany may need to know this > to rekey the connection or something. Yes, we have to send SIOCSIWAP event after every association. >> Are there any activities to implement something like a "background >> scanning" in STA Mode? > > Some drivers already do this (ipw for example), but I don't think > background scanning is really implemented in mac80211 at this time. My understanding is that mac80211 assumes user space to do this. I think wpa_supplicant doesn't do that currently, it only issues a scan if it receives a disassociation event. (Please correct me if I'm wrong.) > mac80211 certainly will handle beacons and probe responses _on the > same channel_, but I don't believe there is any sort of > multi-channel background scanning going on, nor should there really > be unless it can be made _very_ fast. You don't want the driver > doing a multi-channel background scan while you're using VOIP. If the STA is stationary, then background scanning isn't that beneficial, that's true. But if STA is moving, when there are benefits from background scanning because of faster roaming. I haven't measured it ever, but I assume that background scanning and roaming to an another AP beforehand is always faster than loosing a connection. The way I see this is that mac80211 should follow the connection quality (RSSI, transmission failures, beacon losts, etc) and signal userspace if the connection quality gets low and the signal would then trigger background scanning in user space. If the signal gets better, mac80211 would send a signal stating so and user space would turn off background scanning. If background scanning affects the normal data transfer too much we can always try to optimise the scan, for example by scanning every third channel at a time or something similar. >> A background scanning will allow a STA to observe the neighbourhood >> for new APs. > > Right. > >> There are a few drivers that provide this functionality today. The >> intention is to reduce Handover latency of a mobile STA, when it >> switches from one AP to an other AP. > > Again, within the same ESS? I think he is talking about roaming in same ESS here. >> What do you think: Is it interessting for you, to work jointly on >> these challenges? > > Personally I think anything we can do to make intra-ESS handover faster > is a good thing. wpa_supplicant in userspace is obviously required here > for WPA roaming and it can handle things like preauth and other bits of > fast reauth defined in the WPA specs. Since that's where things are > going, it's going to need coordination between both the driver and the > supplicant to get right. I'm very interested about this as well. I expect to work on this more in a month or two. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
