802.11n Issue with 48/54Mbps Data Rate WLANs

Unanswered Question
Oct 1st, 2009

Environment:

1. 1 building

2. 6 floors

3. 8 1142 APs per floor

4. APs no more than 50' apart

5. 2 4404 WLCs

Background:

I have disabled all of the data rates below 48Mbps, set 48Mbps to Require, and set 54Mbps to Supported. After walking around and surveying the environment, these settings appear to be spot on. I am achieving a decent cell size with just the right amount of overlap.

As for the 802.11n configuration, the 2.4GHz and 5GHz frequencies are configured for 20MHz channels due the number of a/b/g clients. The plan is to phase these out for a/b/g/n clients over the next couple years. At some point down the road, we will enable the 40MHz channel width for the 5GHz frequency. Also, all M rates are currently enabled, WMM is enabled, and we are using WPA2 with AES encryption.

Issue:

I am having a problem with 802.11n clients using the Intel ProSet. The clients will initially connect and obtain an IP address, but in a matter of seconds (usually after trying to send some data), it disconnects and things begin to hang up to the point where a reboot is necessary to properly restore it. This is happening on multiple laptops, and with both Dell and Lenovo machines. If you go into the driver and disable 802.11n, the client will connect. The problem is with the 802.11n functionality.

Prior to disabling the 24Mbps (set to Required) and 36Mbps (set to Supported), the clients were working without an issues.

Has anyone else experienced a similar issue? Has anyone been successful disabling all rates except for 48/54Mbps in an 802.11n deployment? What else might I be missing?

Due to change windows, we have not fully confirmed that the issue is with the data rates. Our next step will likely be to re-enable the 24/36Mbps data rates and see if the clients work without a hitch. The last thing we did prior to seeing this issue, however, was disabling these rates and rebooting the APs.

Thanks in advance,

Kevin

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
ericgarnel Thu, 10/01/2009 - 07:16

have you tried the same test with a different client? I have had mixed results with intel cards over the years

ccie14989 Thu, 10/01/2009 - 09:03

I have tried using the Cisco Secure Services Client, as well as the Windows Wireless Zero client. I get the same result. It connects, and then hoses. When it goes, strange things happen. The client will no longer connect to the network, despite a disable/enable. When I type ipconfig, it hangs and never shows any output.

I am really hoping that it does not work when we enable 24/36, and that the issue points to something else. The only thing we are going on right now is that is the last thing we remember changing.

mthurman Fri, 10/02/2009 - 10:10

This is a known issue that Cisco and Intel are currently working. Many users have completely disabled 802.11n capability until the issue is resolved. Since I only have a few 1142's at one site, I have let the clients set their laptops to 802.11a only and that seems to control the issue, but of course is not a good recommendation, only a stop-gap.

Very interesting.. any cisco bug references for this?

I have seen this issue in one building where I am using 22 1132's with only 2 1142

s and it occurs only in the coverage area with the 1142's (where n is enabled).

And most recently - I have been testing an 1142 converted to autonomous - MANY problems with 5ghz and intel clients staying connected.

chad_teal Tue, 10/27/2009 - 16:17

I ran into the same issue. We had to disable Aironet Extensions for the SSID that we have setup for "N" clients. We also disabled MFP. The funny thing was that it was only certain versions of the 4965 cards. It was almost like we had two different shipments. The 5100s worked fine. Intel also had us upgrade to 12.4.0.21 drivers. Hope this helps!

Actions

This Discussion

 

 

Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode