Controllerless Networks

We have a controllerless setup, and in one building, I am seeing the famed "AP is resource constrained" issue with a user trying to connect a Playstation (it has the mac address 5c:96:56:60:95:43).

90:4c:81:cb:69:2e-bldg1# show ap debug mgmt-frames

Traced 802.11 Management Frames
-------------------------------
Timestamp        stype         SA                 DA                 BSS                signal  Misc
---------        -----         --                 --                 ---                ------  ----
Feb  9 18:04:12  auth          90:4c:81:36:92:e0  5c:96:56:60:95:43  90:4c:81:36:92:e0  15      AP is resource constrained (seq num 0)
Feb  9 18:04:12  auth          5c:96:56:60:95:43  90:4c:81:36:92:e0  90:4c:81:36:92:e0  0       -
Feb  9 18:03:53  deauth        90:4c:81:36:92:e0  5c:96:56:60:95:43  90:4c:81:36:92:e0  15      - (internal only)
Feb  9 18:03:53  auth          90:4c:81:36:92:e0  5c:96:56:60:95:43  90:4c:81:36:92:e0  15      AP is resource constrained (seq num 881)
Feb  9 18:03:53  auth          5c:96:56:60:95:43  90:4c:81:36:92:e0  90:4c:81:36:92:e0  0       -
Feb  9 18:03:37  deauth        90:4c:81:36:92:e0  5c:96:56:60:95:43  90:4c:81:36:92:e0  15      - (internal only)
Feb  9 18:03:37  auth          90:4c:81:36:92:e0  5c:96:56:60:95:43  90:4c:81:36:92:e0  15      AP is resource constrained (seq num 0)
Feb  9 18:03:37  auth          5c:96:56:60:95:43  90:4c:81:36:92:e0  90:4c:81:36:92:e0  0       -
Feb  9 18:03:25  deauth        90:4c:81:36:92:e0  5c:96:56:60:95:43  90:4c:81:36:92:e0  15      - (internal only)
Feb  9 18:03:25  auth          90:4c:81:36:92:e0  5c:96:56:60:95:43  90:4c:81:36:92:e0  15      AP is resource constrained (seq num 2969)
Feb  9 18:03:25  auth          5c:96:56:60:95:43  90:4c:81:36:92:e0  90:4c:81:36:92:e0  0       -

Now, I tried the advice of upping the max-clients-threshold.  So my running config looks like this (on the master):

90:4c:81:cb:6e:0c-master# show running-config | include max
 max-tx-power 127
 max-authentication-failures 10
 max-clients-threshold 128
 max-authentication-failures 10
 max-clients-threshold 64

This AP is in a building with another AP.  There are minimal clients connected to these APs (maybe 3-4 per AP).  I don't see how we can have any sort of resource constraint.

I am not, by any means, an AP expert, but I'm all we have.  What can I do in order to figure out why this is happening?  I've reached the extent of my expertise and my knowledge of what to do with Google.

That message is also sent for clientmatch load balancing, sticky client and band steering.

What does that mean?

Can you point me in the direction of how to troubleshoot the issue?

I don't think I have load balancing turned on.  But I do have band steering turned on.  Can you explain why that could be causing this issue?

To narrow down the question:

- Can the Client device connect at all?

- What version of instantOS is this (that will narrow it down and to get the correct commands to see what client match is doing).

As per the second question, this is ArubaOS Model 303, version 8.3.0.0.

So I am looking through the syslog, and I see odd stuff, although I'm not proficient enough to understand what is happening.

They still have the old, legacy Wifi plugged into the switch in this building.  But when I look at the Aruba logs, I am seeing things like this:

Feb  9 18:00:19 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.86.64-5c:96:56:60:95:43
Feb  9 18:00:25 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.107.56-5c:96:56:60:95:43
Feb  9 18:01:02 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.86.64-5c:96:56:60:95:43
Feb  9 18:01:06 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.107.56-5c:96:56:60:95:43
Feb  9 18:01:34 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.86.64-5c:96:56:60:95:43
Feb  9 18:01:37 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.107.56-5c:96:56:60:95:43
Feb  9 18:02:17 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.86.64-5c:96:56:60:95:43
Feb  9 18:02:21 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.107.56-5c:96:56:60:95:43
Feb  9 18:02:49 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.86.64-5c:96:56:60:95:43
Feb  9 18:02:51 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.107.56-5c:96:56:60:95:43

192.168.107.x is not the correct VLAN for this network, which is weird, but it is the VLAN of the master AP.  192.168.86.x is what the legacy router is assigning, and it's a dumb AP in the sense that the old AP has it's own DHCP address, and is double NAT'ing everything behind it.

But after all of these rap_bridge_user_handler messages, the following log lines show up:

Feb  9 18:03:15 192.168.100.13 stm[2600]: <501105> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  Deauth from sta: 5c:96:56:60:95:43: AP 192.168.100.13-90:4c:81:36:a7:60-90:4c:81:cb:6a:76-bldg1 Reason STA has left and is deauthenticated
Feb  9 18:03:15 192.168.100.13 cli[2570]: <541004> <WARN> <192.168.100.13 90:4C:81:CB:6A:76>  recv_sta_offline: receive station msg, mac-5c:96:56:60:95:43 bssid-90:4c:81:36:a7:60 essid-EnterpriseWifi.
Feb  9 18:03:26 192.168.100.12 stm[2600]: <501094> <NOTI> <192.168.100.12 90:4C:81:CB:69:2E>  Auth failure: 5c:96:56:60:95:43: AP 192.168.100.12-90:4c:81:36:92:e0-90:4c:81:cb:69:2e-bldg1 Reason AP is resource constrained
Feb  9 18:03:26 192.168.100.12 stm[2600]: <501106> <NOTI> <192.168.100.12 90:4C:81:CB:69:2E>  Deauth to sta: 5c:96:56:60:95:43: Ageout AP 192.168.100.12-90:4c:81:36:92:e0-90:4c:81:cb:69:2e-bldg1 handle_sapcp
Feb  9 18:03:26 192.168.100.12 stm[2600]: <501080> <NOTI> <192.168.100.12 90:4C:81:CB:69:2E>  Deauth to sta: 5c:96:56:60:95:43: Ageout AP 192.168.100.12-90:4c:81:36:92:e0-90:4c:81:cb:69:2e-bldg1 Sapcp Ageout (internal ageout)
Feb  9 18:03:29 192.168.100.13 stm[2600]: <501093> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  Auth success: 5c:96:56:60:95:43: AP 192.168.100.13-90:4c:81:36:a7:70-90:4c:81:cb:6a:76-bldg1
Feb  9 18:03:29 192.168.100.13 stm[2600]: <501095> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  Assoc request @ 18:03:29.003710: 5c:96:56:60:95:43 (SN 2752): AP 192.168.100.13-90:4c:81:36:a7:70-90:4c:81:cb:6a:76-bldg1
Feb  9 18:03:29 192.168.100.13 stm[2600]: <501095> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  Assoc request @ 18:03:29.004031: 5c:96:56:60:95:43 (SN 2752): AP 192.168.100.13-90:4c:81:36:a7:70-90:4c:81:cb:6a:76-bldg1
Feb  9 18:03:29 192.168.100.13 cli[2570]: <541004> <WARN> <192.168.100.13 90:4C:81:CB:6A:76>  recv_sta_online: receive station msg, mac-5c:96:56:60:95:43 bssid-90:4c:81:36:a7:70 essid-EnterpriseWifi.
Feb  9 18:03:29 192.168.100.13 sapd[2589]: <326271> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76> |ap| AM: New Node Detected Node = 5c:96:56:60:95:43 SSID = EnterpriseWifi BSSID 90:4c:81:36:a7:70
Feb  9 18:03:29 192.168.100.13 stm[2600]: <501100> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  Assoc success @ 18:03:29.007899: 5c:96:56:60:95:43: AP 192.168.100.13-90:4c:81:36:a7:70-90:4c:81:cb:6a:76-bldg1
Feb  9 18:03:29 192.168.100.13 stm[2600]: <501100> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  Assoc success @ 18:03:29.008214: 5c:96:56:60:95:43: AP 192.168.100.13-90:4c:81:36:a7:70-90:4c:81:cb:6a:76-bldg1
Feb  9 18:03:29 192.168.100.13 stm[2600]: <501201> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  stm_derive_user_vlan_and_role_by_mac_oui_on_assoc_req774: mac-5c:96:56:60:95:43, role-EnterpriseWifi, intercept-0
Feb  9 18:03:29 192.168.100.13 cli[2570]: <541004> <WARN> <192.168.100.13 90:4C:81:CB:6A:76>  recv_stm_sta_update: receive station msg, mac-5c:96:56:60:95:43 bssid-90:4c:81:36:a7:70 essid-EnterpriseWifi.
Feb  9 18:03:29 192.168.100.10 cli[2569]: <541004> <WARN> <192.168.100.10 90:4C:81:CB:6E:0C>  recv_sta_update: receive station msg, mac-5c:96:56:60:95:43 bssid-90:4c:81:36:a7:70 essid-EnterpriseWifi.
Feb  9 18:03:29 192.168.100.13 stm[2600]: <501199> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  User authenticated, mac-5c:96:56:60:95:43, username-, IP-0x386ba8c0, method-Unknown auth type, role-EnterpriseWifi
Feb  9 18:03:31 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.107.56-5c:96:56:60:95:43
Feb  9 18:03:32 192.168.100.13 sapd[2589]: <326278> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76> |ap| AM: STA 5c:96:56:60:95:43 Authenticated with AP 90:4c:81:36:a7:70
Feb  9 18:03:32 192.168.100.13 stm[2600]: <501216> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  rap_bridge_user_handler 14868: user entry created for 192.168.86.64-5c:96:56:60:95:43
Feb  9 18:03:32 192.168.100.13 stm[2600]: <501105> <NOTI> <192.168.100.13 90:4C:81:CB:6A:76>  Deauth from sta: 5c:96:56:60:95:43: AP 192.168.100.13-90:4c:81:36:a7:70-90:4c:81:cb:6a:76-bldg1 Reason STA has left and is deauthenticated

This just gets repeated and repeated.

So it looks like it does get a successful connection at some point (Auth success), but then things go awry.

Any clue?

If you want to emulate what the previous AP is doing, put the instant AP on the same VLAN that gives out 192.168.86.x.  Setup the SSID and make it "Network Assigned" and make the VLAN VLAN 1.

Your AP would be giving the client a separate private range and natting it, if you made the SSID "Virtual Controller Assigned".

I definitely don't want to emulate the old one.  I want the old one to go away.

I want them to connect to this one and get dropped on the right VLAN.  I don't know why it's not working for this, but phones and computers are working fine.

Is there a way to free up the resources that are supposedly getting maxed out?  

Turn off client match features and see if you still get that message:  https://www.arubanetworks.com/techdocs/Instant_42_WebHelp/InstantWebHelp.htm?_ga=1.43038629.1615771646.1440445030#UG_files/ARM/Configuring_ARM-Features.htm?Highlight=client%20match

I was sidetracked because you were speaking about VLANs.

So as a follow up, I checked, and client match was not on.  I tried changing the setting to force to 5GHz, but that didn't help.

In the end, shutting off the other wifi fixed all of the problems.  So I guess the collissions in the frequencies were really causing issues.