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.
Or is this more likely something in our radio environment or insufficient coverage etc? Our wireless LAN engineers are currently investigating this, but I'd be interested to hear the experience of others.
We see some of that. To be honest, this is one of the things about the Meru system that we're moving to that I really like. Since the wireless cloud appears to the clients as a single AP (even though its supported by multiple APs), the client's roaming algorithm never comes into play. This means no drops during reassociation/ reauthentication, because there never *is* a reassociation/ reauthentication.
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?).
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.
--Mike ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
