Summary:

How to troubleshoot smartphone or tablet that can't connect to Wi-Fi network due to legacy data rates (e.g., 802.11a, 802.11b and 802.11g).

Problem:

Staff member's personal smartphone won't connect to the guest Wi-Fi network.  All other devices connect to wireless network without issues.

Problem Device:

• Older Kyocera Android phone.  
• Problem device only connects with 2.4GHz radios.

Topology:

Multiple access point and wireless controller.  Single 2.4GHz SSID broadcast throughout the office.  Recent changes were made to roaming, data rates/ cell size, and power tuning (background).  Independent BSSIDs broadcast on separate radios: 802.11na and 802.11ng.    Legacy 802.11b data rates are disabled. The network continues support for 802.11G data rates (i.e., 54 Mbps):
set service-profile Guest_2.4 transmit-rate 11g mandatory 12,24.0,36.0,48.0,54.0 disabled 1.0,2.0,5.5,6.0,9.0,11.0,18.0 beacon-rate 24.0 multicast-rate AUTO

Solution:

1. Identify client session:
   

   
   *WLC# sh sessions network verbose
   
   Name:               last-resort-Guest 2.4GHz-570
   
   SSID:               Guest 2.4GHz
   
   MAC:                6c:xx:xx:xx:xx:xx
   
   AP/Radio:           1/1
   
   State:              DEASSOCIATED
   
   Device type:        android-generic (AAA)
   
   Radio type:         802.11ng
   
   Last packet rate:   6.0 Mb/s
   
   Last packet RSSI:   -49 dBm
   
   Last packet SNR:    46
   

   Session interpretation:
   
   • Session state is deassociated.  
   • Excessive of roaming attempts.  
   • Good signal strength and SNR.  
   • Last packet rate is only 6.0 Mb/s. 
   Data indicates the phone probably uses legacy wireless standards -it's old!


2. Enable log tracing to debug connection attempts:
   *WLC#set log trace enable severity debug
*WLC#set trace dot1x level 10 mac
*WLC#set trace sm level 10 mac
*WLC#sh log trace
SM Apr 14 13:45:08.197931 DEBUG SM-EVENT: Cannot set ipaddr for 6c:76:60:59:9e:6a
SM Apr 14 13:45:08.743477 DEBUG sm_do_flood_announce: 6c:76:60:59:9e:6a flood announce
SM Apr 14 13:45:16.176513 DEBUG SM-EVENT: (4601) rssi -69, rate code 0x0018, idle 48 secs
SM Apr 14 13:45:16.176661 DEBUG SM-EVENT: (4601) idle timer 132755 left, reset to 132000 ms
SM Apr 14 13:45:16.177599 DEBUG SM-EVENT: (4556) rssi -56, rate code 0x0018, idle 9 secs
SM Apr 14 13:45:16.177756 DEBUG SM-EVENT: (4556) idle timer 150259 left, reset to 171000 ms
SM Apr 14 13:45:16.179532 DEBUG SM-EVENT: (5415) rssi -76, rate code 0x0018, idle 20 secs
SM Apr 14 13:45:16.179653 DEBUG SM-EVENT: (5415) idle timer is tracking (160258 to go)
SM Apr 14 13:45:16.180066 DEBUG SM-EVENT: (4551) rssi -63, rate code 0x0018, idle 6 secs
SM Apr 14 11:12:44.674414 DEBUG SM-DOT11: sm_dot11_handle_deassociate: ev type 5 (good), token 0, mac 6c:76:60:59:9e:6a
SM Apr 14 11:12:44.674576 DEBUG SM-STATE: (2462) mac 6c:76:60:59:9e:6a, flags 1801800028834dh, to change state ACTIVE -> DEASSOCIATED, by sm_dot11_handle_deassociate
Log Interpretation:
   
   • SM=Session Management.
   • SM-DOT11=World Mode Multi-Domain Operation.  The DOT11D option makes access points advertise local settings, such as frequencies and power levels.
   • Rate code 0x0018 = 11Mb per Multi-band Atheros Wi-Fi (MADwifi) 5212.
   The deassociation was based on DOT11D.  In other words, due to AP frequency or power level restrictions.


3. Check the configuration for frequency or power restrictions:
   set service-profile Guest_2.4 transmit-rate 11g mandatory 12,24.0,36.0,48.0,54.0 disabled 1.0,2.0,5.5,6.0,9.0,11.0,18.0 beacon-rate 24.0 multicast-rate AUTO
Snap!  The service profile indicates that devices must connect at a minimum, 12Mbps -normally good policy.  However, we have a single client that can only connect at 6Mbps.

Available Options:

1. Remove 6Mbps from the list of disabled data rates.  N.B., Legacy devices on the BSSID has a negative impact for the entire wi-fi network. Is one person worth the trouble?  It certainly is if that person is your boss!
   
2. Create a dedicated legacy SSID -diplomatic solution.
3. Ask the employee to get rid of the stone-age device!   Suggest or provide a modern device that handles 802.11na!

 Thant's It!
http://www.cisco.com/web/techdoc/wireless/access_points/online_help/eag/123-02.JA/1400BR/h_ap_network-if_802-11_c.html
http://web.mit.edu/freebsd/head/sys/dev/ath/ath_hal/ar5212/ar5212_phy.c

Takeaway:  Troubleshooting AD user password changes using 802.1X authentication.

• Log errors indicate a user password error. 
• Microsoft EAP (PEAP) is set to use EAP-MSCHAPV2.  I made sure "allow user to change password" is checked.

• Multiple WLC2s at multiple geographic locations working in a cluster. 
• We use 802.1X authentication that connects to Microsoft Windows Network Access Server.  Policy setup that allows Radius to authenticate against Active Directory.

• I set termination-action to 1 in case the default disconnect behavior was terminating the re-attempt.  This didn't help.

• What is the correct vendor code?  Do I use a Juniper code or the Trapeze code?
• What are the specific configurations for the attribute?
• Do I need to remove anything from the NAS policy in order for the vendor attribute to work?

Solution:   

     My hypothesis was incorrect.  I first changed the Juniper WLC 802.1X authentication method from "PEAP-MSCHAPV2" to "Pass-Through":  

PEAP-MSCHAPV2:

               #set authentication
               #dot1x ssid SIDDNAME ** peap-mschapv2 webview-default

 Pass Through:

               #set authentication
               #dot1x ssid SIDDNAME ** pass-through webview-default

     Pass-Through should have allowed direct authentication between the Windows client and the Microsoft NAP server.  I reasoned vendor specific attributes were not necessary between a Windows server and client.  Expired accounts continued to fail authentication after the change to the authentication method.

      My focus changed to the Windows client wireless settings.  The problem specifically stemmed from the client's wireless single sign-on (SSO) settings.  I plan to implement computer + user authentication at a future date but for the time only user mode is enabled.

      Ironically, SSO is designed to resolve problems with user-only authentication:

•  User cannot log into the domain because connection to the domain controllers are not available.  Locally cached credentials are used to authenticate (sometimes incorrectly) to the Radius server.

     I removed all SSO options from the Windows wireless client under "advanced" settings:





      N.B., Under the EAP-MSCHAP v 2 configuration, I was able to check "Automatically use my Windows logon name and password (and domain if any)":







      After I removed SSO expired accounts were able to pick a new password and complete the network connection.  I still believe it is still possible to use SSO with only 802.1X user authentication -my situation didn't require further research.  I also suspect the SSO would have worked, had I used both computer authentication and user authentication.

Last updated  November 15th, 2013 by Steven Jordan.