On Wed, Sep 27, 2006 at 04:49:54PM -0500, Michael Griego wrote: > On Sep 27, 2006, at 3:15 PM, Shumon Huque wrote: > > >Is frequent reassociation the normal behavior in a dense > >deployment of APs? I can understand that it might be for > >highly mobile stations like wireless VoIP phones. But our > >environment is composed of mostly stationary wireless laptops > >in student rooms. My assumption was that roaming typically > >happened when a user moves towards a stronger signal AP and > >at some configured signal quality threshold, the station started > >scanning for a better AP. Am I wrong? > > The truth of the matter is that the roaming algorithm in many wifi > drivers and chipsets is crap. In a case where you have clients > sitting where two APs are showing roughly the same signal strength to > a client, the client may flap back and forth as the environment > causes one to look stronger this second then weaker the next. Having > a dense AP deployment exacerbates the situation.
Well, that's pretty sad :-( It seems to me that the correct behavior should be to try to maintain a stable association with the same AP as long as it's signal quality hasn't deteriorated beyond a certain threshold, or until you've experienced a certain number of retransmission attempts or other failures. > >Do we need a fast roaming solution to deal with this? Having > >access points and stations able to cache the PMK (Pairwise > >Master Key) would probably help the best, as that would allow > >them to often establish a secure association without conducting > >a heavyweight authentication dialog with the RADIUS server. But > >I'm not sure if access points or typical endstations support this. > >TLS session resumption will probably help a bit also (if supported). > >We use cisco aironet 1200/1100 access points. The clients are > >mostly PCs running SecureW2, Macs running with the built-in > >EAP-TTLS/802.1x support in Mac OS X, and a smaller number of > >Linux machines. > > Having TLS session resumption enabled in the RADIUS server would be > the most open solution you could pursue from the "fast reauth" > scenario. Having fast reauth, though, just means the drop during > reassociation/reauth is shorter. It doesn't take care of the *cause* > of the problem whatever that is (overly dense?). Yup, we're looking into both TLS session resumption and PMK caching as alleviating measures. But I agree, we still need to attack the cause of the problem. > One thing I noted is that you said that your clients are doing a DHCP > renew. If that's true, then they're not truly "roaming", but > actually dropping the connection completely then coming back online. > Something else may be a factor in that case. Well, I've not actually verified the DHCP bit. But it seems to me that the correct behavior would involve at least performing a DHCPREQUEST of your previous address (possibly followed by a DHCPDISCOVER), because there is no guarantee that the AP you're transitioning to is giving you access to the same IP subnet (even if it has the same SSID). --Shumon. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
