cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2689
Views
0
Helpful
6
Replies

Client AP Selection

Recently, as funds allow, I have been building some coverage overlap into some of the larger areas of the wireless network that I run.

My standard for an indoor AP is the 1142 series, atatched to dual 5508 controllers running 7.0.98.0 code.

Some of the APs have adjusted power levels and are no longer running at full power.

I have run into a situation where my boss is experiencing frequent disconnects with his wireless phone (CP9971...a wireless stationary desk phone). there are two access points within -60 db of each other in our area of the building. For some reason, his phone favors the AP furthest from his office, rather than the AP that is much closer. The phone has a wireless survey mode and sometimes it even fails to see the AP much closer. My boss's office has standard sheetrock walls, which shouldn't be a problem for WiFi.

Both access points have about 6 clients each attached. I locked the phone dow to 5Ghz, thinking it would run into less issues, as 5Ghz is generally a cleaner band with more available space. This still did not help.

I have run into this issue with some laptops...all I could get out of TAC was "update the drivers"....and I tried that...it didn't work...

This happens ocasionally with the CTO's laptop....disconnects and favoring the "wrong" AP....and I have not been able to track it down....

Updated the drivers and still no luck on that one as well...his laptop is a Lenovo Thinkpad....

Are there any parameters on the WLAN that I need to look at? The Voice WLAN uses WPA2/PSK while the Data WLAN uses PEAP/MSCHAPV2 as the authentication solution....

Any suggestions would be much appreciated.

Thanks,

Phill

1 Accepted Solution

Accepted Solutions

That my friend is a very good question.

The session timeout is a forced re-authentication. If a client does not reauthenticate to renew the session timeout, they are deauthenticated.

However, in the case of dot1x clients, you might have a client re-authenticating behind the scenes which extends the session.

You should check out "debug client " between a client doing PSK and dot1x and see what happens at the session timeout interval.....  I wouldn't be surprised if one client does some kind of key rotation and never gets deauthenticated.....

Anyhow, back to your question.   For voice deployments I would usually suggest this feature either be completely disabled or at least set to like 8 or 12 hours.  Actually, even for data clients, I often suggest 8-12 hours if anyone has complaints of being deauthenticated.

I honestly don't know the root reason for a session timeouit, but I'd venture a guess to say that in WEP days it was used as a means of making sure a client was still who they claimed to be (maybe to rotate encryption keys at regular intervals?)

View solution in original post

6 Replies 6

Leo Laohoo
Hall of Fame
Hall of Fame

Ok.  For your Voice SSID:

1.  Enable "Media Session Snooping";

2.  Enable "Re-anchor Roamed Voice Clients"

3.  Disable "Aironet IE"

4.  Disable "Client Load Balancing" and

5.  Disable "Client Band Select"

That didn't work....

In WCS, I see it disconnnecting and reassociating every 30 minutes and 9 seconds...this is WPA2/PSK...

I believe the "enable session timeout" box being at 1800 seconds has something to do with this...

Phill

Unchecked the "session timeout" box just see if this is causing the issue with the phone...

With the PSK WLAN, the problem is the session timeout...every 30 minutes, the client reauthenticates...

When I disable the session timeout, the client simply stays connected.

With .1x, I do not see this happening, even though I have session timout enabled (1800 seconds).

I have seen session timeout become a problem with guest access solutions (I bumped mine up to 5 hours)....

I guess the question for me is, is there a good reason to have a session timeout at all on a PSK solution?

Thanks,

Phill

That my friend is a very good question.

The session timeout is a forced re-authentication. If a client does not reauthenticate to renew the session timeout, they are deauthenticated.

However, in the case of dot1x clients, you might have a client re-authenticating behind the scenes which extends the session.

You should check out "debug client " between a client doing PSK and dot1x and see what happens at the session timeout interval.....  I wouldn't be surprised if one client does some kind of key rotation and never gets deauthenticated.....

Anyhow, back to your question.   For voice deployments I would usually suggest this feature either be completely disabled or at least set to like 8 or 12 hours.  Actually, even for data clients, I often suggest 8-12 hours if anyone has complaints of being deauthenticated.

I honestly don't know the root reason for a session timeouit, but I'd venture a guess to say that in WEP days it was used as a means of making sure a client was still who they claimed to be (maybe to rotate encryption keys at regular intervals?)

Thanks,

I went ahead and kept the timeout disabled on the PSK voice WLAN, and set it to 12 hours for everything else, including the .1x WLANS that I have....

Maybe this will help with the CTO's thinkpad....

Phill

Review Cisco Networking for a $25 gift card