RE: [WIRELESS-LAN] Frequent reassociations/reauthentications in 802.1x WLAN

[Chris Hessing]

Title: RE: [WIRELESS-LAN] Frequent reassociations/reauthentications in 802.1x WLAN

Have you looked in your logs to see if the aps are changing channels?  I know older versions of the IOS would only pick a channel on boot, but it seems like newer ones do it during normal operation.  We had a similar issue with a different vendor's gear where the APs would jump channels while users were connected.  It would pull the carpet out from under the user, and they would have to find a new AP, which in turn caused a reauth.

The problem with this situation is that you probably wouldn't notice it on a network that doesn't use 802.1X.  If you have 802.1X it adds enough of a load on the server to draw your attention.

Something else that I am surprised hasn't been mentioned is power output.  If the reauth is happening in areas where the APs are more densly populated, it may very well be that you have the power turned up too high.  The common way to install an AP is to slap it on the wall, and crank the power all the way up to get maximum distance.  But, that isn't always the best way to handle things.  In a dense AP deployment, you are better off turning the power down.  There are plenty of tools out there that will let you see what your coverage looks like. 

Last, but possibly not least, I have been working with a client that is having some similar issues.  However, I am not sure that the client is actually disassociating.  It seems that the AP will randomly decide to request a reauth.  In this case, the reauth can be anywhere between 5 seconds to 5 minutes.  Unfortunately, I cannot get access to their logs to determine if the AP is really disassociating or not.


As far as knowing if TLS session resumption (fast reauth, or whatever your chosen EAP type calls it).  If you don't mind using a sniffer, it is pretty easy to determine if it is working.   Sniff an authentication when you are sure that session resumption won't work.  (This will vary depending on settings on your server.  But, first auth in the morning is usually a safe bet.)  You will see that it probably takes ~8 round trips to authenticate.  (Assuming you are using PEAP.  TTLS is 1-2 round trips shorter, and TLS is shorter than that.)  A session resume should take less than half as many round trips.  So, if later authentications show fewer round trips, you can be fairly confident that session resumption is working for you.  However, keep in mind that users have control over if their end does session resumption.  So, if they turn it off, you lose any advantage you may have otherwise had.

Or, if you are really curious, you could look at the TLS session decodes.  There will be an indication in there that the session is resuming.

Hope this helps!


-----Original Message-----
From: Foggi, Nicola [mailto:[EMAIL PROTECTED]]
Sent: Fri 9/29/2006 5:19 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Frequent reassociations/reauthentications in 802.1x WLAN


Colleen,

We aren't running 802.1x, but we had a similiar problem with reassociations running Cisco 12xx AP's, we tracked it down to these 2 commands:

dot11 activity-timeout unknown default 3600
dot11 activity-timeout client default 3600

The default for an unknown device (which most devices are to Cisco AP's) is 30 seconds :)  The timeout for client is I think 5 mins, but don't quote me on that one.  Once we bumped it up the complaints as far as I know have disappeared.

Nicola

-----Original Message-----
From: Colleen Szymanik [mailto:[EMAIL PROTECTED]]
Sent: Thu 9/28/2006 10:25 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Frequent reassociations/reauthentications in   802.1x WLAN

Jorge,
Thanks for the response.  We are using Cisco AP 1131 and AP 1242 - we
don't use a controller, only WLSE to manage.  We have the basic default
radio settings enabled.  We tried turning off the non-aironet extensions
and the problem still persists.  The intervals seem to be regular - for
some it's about every 30 sec and for others it's about every few
minutes.  We have dynamic channels set so the AP will search for the
least congested channel.  And the strange thing is that this problem
occurs on some APs and not on others with some clients and not with all
of them.  We have been trying the driver update and that seems to only
fix the problem for a little while and then it comes back.
Colleen Szymanik
----------------------------
University of Pennsylvania
Network Engineer

Jorge Bodden wrote:

> Shumon,
>
> We used to have the same problem when we had the Aironet solution a
> couple of years back.  It was actually due to the APs sending a
> re-association packet/frame to the device, even if that device was
> directly underneath the AP.  What type of platform are you currently
> running your infrastructure on?  How dense is your environment?  Do
> you have dynamic channel/power assignment or are you doing it
> statically?  Then we had a similar problem, when we deployed to the
> Airespace solution, which was due to 2 bugs; one on the controller and
> another on the router.  Those are things you might want to look at a
> little bit.
>
> Although the authentication mechanism is what is being impacted, it
> does not seem to be the source of your problem, for the simple fact
> that people are authenticating.  Have you sniffed the air?  You could
> try running some tests by leaving a device connected and monitoring it
> and what type of traffic it is receiving.  Look to see what is
> happening with the device when it is disconnecting.  Check to see if
> it is happening at random intervals, or the intervals are more
> periodic.  Whatever you do, do not ignore it because there are no
> complaints.  I am sure that are many of us here in the group whom in
> ignoring small problems have gotten burnt.
>
> Let us know how it works out.
>
> Thanks.
>
> Jorge
>
> Shumon Huque wrote:
>
>> We rolled out a WPA/802.1x authenticated WLAN to our student
>> residences this semester. We're using EAP-TTLS with PAP as the inner
>> authentication protocol. The EAP servers are a set of centralized
>> RADIUS servers that perform Kerberos5 password verification to our
>> KDCs in the backend.
>>
>> We've noticed several problems that we didn't observe when we had it
>> running on a much smaller scale in our own offices.
>> A large number of users seem to be repeatedly authenticating,
>> some of them as frequently as every 30 seconds or every few
>> minutes. Some debugging revealed that these users are frequently
>> oscillating their associations between a number of different
>> access points. A smaller number of users keep reassociating with
>> the same access point. This is causing a very large load on the
>> authentication server infrastructure, which we've temporarily
>> worked around by load balancing the APs across additional RADIUS
>> servers.
>> However, we're also assuming that this is causing lots of user
>> visible performance problems due to roaming latency (scan,
>> reassociate, authenticate, 802.11i handshake, DHCP address
>> acquisition etc). Surprisingly, not many users have complained.
>> Perhaps they are only browsing the web or using other non-
>> interactive apps which can tolerate delay. Or they might
>> simultaneously have a wired ethernet connection.
>>
>> 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?
>>
>> 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.
>>
>> 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.
>>
>> Thanks for any advice!
>> ---
>> Shumon Huque                3401 Walnut Street, Suite 221A,
>> Network Engineering            Philadelphia, PA 19104-6228, USA.
>> Information Systems & Computing        (215)898-2477, (215)898-9348
>> (Fax)
>> University of Pennsylvania / MAGPI.    E-mail: shuque -at- isc.upenn.edu
>>
>> **********
>> Participation and subscription information for this EDUCAUSE
>> Constituent Group discussion list can be found at
>> http://www.educause.edu/groups/.
>>  
>
>
>
>
>
> --------------------
>
> This electronic message is intended to be for the use only of the
> named recipient, and may contain information that is confidential or
> privileged.  If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution or use of the
> contents of this message is strictly prohibited.  If you have received
> this message in error or are not the named recipient, please notify us
> immediately by contacting the sender at the electronic mail address
> noted above, and delete and destroy all copies of this message.  Thank
> you.
>
> **********
> Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at
> http://www.educause.edu/groups/.

**********
Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.



**********
Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.