Wireless Access

We've been having a LOT of problems recently with windows clients on our Aruba wireless.  The user will log into the network, get authenticated, apparently get an IP, but cannot actually communicate on the network.  The taskbar will show the connection as "limited."  Running IP config shows an appropriately assigned IP address but the connection does not work (can't even ping the gateway for the assigned vlan).

We've seen this predominantly with Windows 8.x and 10, although we get an occasional Win 7 or Mac with the problem.  I don't recall ever seeing it with a phone, only laptops.  The problem tends to appear after the device has been off-campus or after waking from being power suspended.  We're getting a handful of clients with the problem each week (out of about 1500 students).  We're running Aruba OS 6.4.3.5 on 3600 and 7210 controllers with a mix of AP types (105, 125, 205h, etc).  The client is successfully authenticating against our radius server.

What we've tried so far:
1. disabling IPv6 (we don't use it anywhere on campus)
2. disabled 'Enable Pairwise Master Key (PMK) caching' in the network "advanced" security settings.
3. reinstalling wifi drivers on the client
4. removing the client adapter and drivers and reinstalling

We can usually provide a temporary fix the problem by creating a dummy reservation for the claimed IP and then having the user reconnect to the wireless.  This seems to force the assignment of a new IP.  After doing this we may or may not sett the same device/user back with the problem.  I'd like to be able to provide a permanent fix for these clients.  We've done quite a bit of searching through airheads and MS articles without success so far. 

EDIT: changed 'desktops' to 'laptops'

What encryption/authentication is the client using?

What is the user role that the user gets placed in after authentication (show rights <role>)?

---

@cjoseph wrote:

What encryption/authentication is the client using?

---

PEAP and MSCHAPv2 to authenticate against our radius server.  WPA2 Enterprise (AES).

---

What is the user role that the user gets placed in after authentication (show rights <role>)?

---

We have several custom roles that the user is placed in depending on the results of their radius authentication.  The authentication is returning the correct roles for any given user.  The same who has this problem often has a successful connection with their cell phone at the same time. 

What wi-fi chipsets are in the laptops experiencing this issue?

---

@thecompnerd wrote:

What wi-fi chipsets are in the laptops experiencing this issue?

---

The ones we can recall are Marvell, Qualcomm Atheros, and Intel.  There are probably some others but we haven't kept track of them.

Okay, just thought I'd check. There are some issues with Intel 7260/7265 showing "limited connectivity" in older drivers; I believe anything pre-18.12.0.3.  Sounds like your issue is widespread.

---

@Anteater wrote:

---

@cjoseph wrote:

What encryption/authentication is the client using?

---

PEAP and MSCHAPv2 to authenticate against our radius server.  WPA2 Enterprise (AES).

---

What is the user role that the user gets placed in after authentication (show rights <role>)?

---

We have several custom roles that the user is placed in depending on the results of their radius authentication.  The authentication is returning the correct roles for any given user.  The same who has this problem often has a successful connection with their cell phone at the same time. 

---

Did you change any of the timers in your Aruba installation?  what is the output of "show aaa timers"?

We haven't made any changes to the timers.

 #show aaa timers

Global User idle timeout = 900 seconds
Auth Server dead time = 10 minutes
Logon user lifetime = 5 minutes
User Interim stats frequency = 300 seconds

The default global user timeout normally looks like this:

Global User idle timeout = 300 seconds
Auth Server dead time = 10 minutes
Logon user lifetime = 5 minutes
User Interim stats frequency = 600 seconds

If you say that you are having DHCP issues, it could be that your DHCP lease time is less than 900 seconds, BUT users are being kept in the user table with the same ip address for more than 900 seconds, which means that your lease assignments are changing faster than users can be aged out.  To solve that your DHCP lease time needs to be more than your user idle timeout (in this case 900 seconds).

Our DHCP leases are set for 2 hours, so we're well over those times. 

Please open a TAC case.  Just seeing those timers changed means you could have more underlying issues that need to be addressed.