Controllerless Networks



I want to add on this topic. we're have the exact same issue and I want to mention, that currently it seems like a general issue with IAP in a  802.11ac deployment, at least with the alcatel lucent IAP225's.


we already troubleshooted the issue and it's pointing out that the issue is already known and has to do with an client match issue in connection with 802.11AC clients/config. On my researches I found serveral post in this forum descriping this problem.



like i mentioned, we're using branded alcatel lucent IAP's and we've opened up a service request there. 


the current sitation:

clients freaquently got kicked out of the wlan and are unable to reconnected, in most cases they do not get DHCP IP after reconnect, even if they are located directly under the accesspoint. 

At the moment it looks like we managed to workaround the issue with:


- upgraded to the lastest firmware
- disabled clientmatch
- diabled 80mhz and even 40mhz channels
- set all IAP IPs staticly
- disabled all IAP firewall features under wlan profil (any any unristricted)
- disabled broadcast filter



so we basicly reduced the configuration to a "better 802.11n wifi"




i hope this issue got fixed soon...



Guru Elite




How many IAPS do you have and how far apart are they?  What is their minimum and maximum power?


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars


Hi joseph


our customer has kind of a high dense deployment, he's only uses wifi without wired lan connection for an enviroment of around 30 users splitted over 3 open space offices.


there are 9 IAP in total:

4x in the first open space office

3x in second open space office

and 2x in two seperate rooms.



this picture were taken off hour when almost no client was connected to the wifi (only some ipad's left in the office)

iap ap overview.png


befor we did some tweaking in the channel settings, about 5 AP's had there 5ghz channel set to 116, so we dediced to configure some of them manually in a pattern of 40,44,48... to make sure there is no co channel indeferience. 

we left the max transmit power to the max but we reduced the  min. transmit power to the minumum of 3db!


let me explain why we enabled a 4 channel strategy instead of go with the default 1,6,11. Like i mentioned we have 4 AP's very close together in one office, and we noticed that even with the min. transmit power set to 3db, no AP throttled down ther power lower than 15db, that caused the issue that even in a idle state there was a utilitsation of 50%...   unfortunatelly there is no way to turn of 2.4radio per AP.. so we dediced to go with 4 channels, which overlap a bit better than go with 3 channel which overlap more.


anyway i don't think that plays into this issue, because most clients stick on the 5ghz band... the issue is not related to an coverage or indeference problem and existst even if we turn of 50% AP's..  



in addition a want to point out, that our first direction in the troubleshooting process was to make sure that the DHCP server is not causing the issue.. 



because the detailed error message leat to that

iap dhcp error.png



we're using an ASA firewall as dhcp server and we can clearly see that all DHCP Discover messaged got answered properly:

dhcp stats.png


I also setup a syslog debug for a short period of time, i attached the logfile. 


please note that the errors which contain "" are probably releated to the circumstanced that i was connected via VPN to the virtualcontroller while i catched the syslog debugs... so you might ignor those messaged.



Guru Elite




The inability to receive DHCP could be an RF issue.  We need to ensure that the RF environment is very good, before we attempt to troubleshoot anything else.


You should have your access point power at min 12 and max 18 on the 5ghz side.  Why?  That is so that a user will not hang on to an access point that is far out of the access point radius, because the signal is still good.  having access points at the max power can cause roaming issues, because clients normally do not attempt to roam until the signal gets "bad enough".  In addition, since your client has an open office space area, RF can travel hundreds of feet, dragging tons of clients into a collision domain, as a result.


You should not use DFS channels, UNLESS a great majority of your clients support it, because not all clients can see DFS channels, so they will probably connect to a sub-optimal access point, and not the one right above it, as a result.  That would make that client connect to an access point further away and that will drag down the performance of all the users who are connected to that access point, because the client will take longer to transmit further away.


You should use 20mhz channels with any density so that you have 9 non-overlapping (non-dfs) channels instead of 4 with 40mhz (non-dfs).  This is because all clients cannot use 40 mhz channels and that means when those clients connect, 20mhz of spectrum will go unused...and other clients cannot use the other 20mhz.


When you have high density, you might want to try increasing the basic and tx rates on that SSID so that the management traffic takes less airtime and reduces your utilization.  by default the lowest management and data rate on the 5ghz is 6mb.  You could try changing it to something like 18 for each, and your utilization will drop.


You also do not have to set static channels.  Make enough channels available and ARM should do its thing.


Since any ip connectivity rides on RF connectivity, you will be able to see if there is an IP issue when you make the RF changes.  It is hard to troubleshoot an IP issue, when there are still RF issues.  There is only so much that Clientmatch can do.


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars
New Contributor


Hmm.. seems like it comes down to something other than an RF issue :smileyindifferent:


Many threads on this specific problem. 


I'm brand new to Aruba and after deploying my first set of IAP-225s am experiencing exactly the same issue.  Definitely no RF issue (RSSI > 60, 3 devices all on seperate channels 1, 6, 11, covering a 5000sq ft indoor area with no significant noise).

Has there been any fix to this known issue?


yes it was definitively not a RF issue. 


we reduced the AP count and monitored the spectrum with some AP's = no effect

we disabled DFS channels = no effect

we tried almost every setting regarding tx rates and power levels = no effect


after we upgraded to it worked immediatelly like a charm.




Search Airheads
Showing results for 
Search instead for 
Did you mean: