I’m installing some XV2-2 ap’s, but I’m experiencing multiple issues with them and also with the maestro on-prem solution. I will try to summarize everything in a very simple way and by points:
Sometimes, connecting to an SSID gives an error endpoint side (not able to connect), without any specific reason. Forcing the re-connection solves this issue (sometimes the user needs to try 1x time, other 3 or 4x times).
The APs are putting most users in the 2.4GHz band, even when there are, for example, only 3 connected devices, one 802.1ac and two 802.11ax, at a (unobstructed) distance of 2.5 meters only! Band steering is turned on in aggressive mode (I have also tried normal), but this behavior doesn’t change, compromising speed’s.
The list of clients connected to the AP takes more than 5 minutes to update on the CNMaestro on-prem side. Even if I press the CNMaestro refresh button (top right corner), the list never gets updated… Basically the refresh button serves no purpose. If you check directly on the AP, the connected users are updated in real time.
I should say that the firmware versions of the AP’s are up to date, and the CNMaestro is also in the latest version.
If there is a refresh button in the maestro GUI, then it should work…
Anyway, what about the band steering issues? For some reason everyone is being connected to 2.4GHz instead of 5GHz, even on agressive mode, and with better signal in the 5GHz frequency vs 2.4…
When I have closed my laptop lid, and reopen it 15 mins later.
If I don’t hit refresh… I don’t see much for a couple mins.
UniF–k used to drive me crazy with the several minutes of time required for the WAPs to update to the java app, then it to be parsed, then fed to the GUI HTTPs server.
I really only look at CN Maestro to see what happened “after the fact” or configure things.
When I wanna see whats going on… I have given into the fact that i have to VPN in and open several webguis to actually get updates.
Practical… no. But its what I have to do if I want close to realtime updates.
As stated… Ruckus takes time. UniFu–k takes time. Meraki takes time. Netgear
ETC.
you WON’T find me making excuses for them… just what I have figured out.
As for the band steering… shut off all the 2.4 radios and see what happens. If devices don’t connect to the 5Ghz radios at that point… you have a start point to diagnoisis.
But log into the WAP and look and see what’s going on. BTW… if you need to submit support logs… they want them per WAP.
Unfortunately, I changed the band steering mode to low and rebooted the AP, but the behavior is still the same. 90% of the time, AX and AC devices connect to the 2.4GHz band. Tried with different smartphones (Samsungs, Oneplus, Huawei), and also with 802.11ax laptops.
I even tried to lower the radio 1 (2.4GHz) power to see how the devices would react, and they still end up connecting to 2.4GHz instead of 5GHz…
Sorry for the delay, but I didn’t have time to do more tests. I will sent it asap.
Meanwhile:
Is it normal that the AP decides to activate ACS with several clients connected, disconnecting all clients due to channel change?
Can you give any tips regarding roaming users? Sometimes the roaming works fine between two AP’s, however, sometimes it doesn’t and the devices keep trying to connect to the farther AP (with -85dBm vs -50dBm from the closer AP).
Is it normal that the AP decides to activate ACS with several clients connected, disconnecting all clients due to channel change?
Yes . It is normal that clients which does not support Channel switch announcement would get disconnected during channel Change.
If you would want to avoid frequent channel change, then you can opt for higher channel hold time value under Auto-rf.
Can you give any tips regarding roaming users? Sometimes the roaming works fine between two AP’s, however, sometimes it doesn’t and the devices keep trying to connect to the farther AP (with -85dBm vs -50dBm from the closer AP).
Ideally it is expected to connect to AP with -55 RSSI. Don’t see a reason for it not to connect untill or unless AP kicks out the client for wrong reasons or the client is not scanning properly to roam at instances. Can you please share more insight like the client tries to connect and gets kicked out during roam? Client tries to connect but fails to acquire IP? Client sticks to the existing AP it is connected to for very long time? Also is the issue seen with any specific client? If yes, can you please share the details about the client.
To further suggest on roaming and Auto-RF, we would like to see the configuration in the AP. It would be helpful if you can provide us with the techsupport.
With the 5 GHz radio on channel 136 you will end up with more clients initially connecting to the 2.4 GHz radio because the 2.4 GHz radio will become operational at least 1 min before the 5 GHz radio. This is because channel 136 is a DFS channel and the radio can not become operational until it spends time at initialization listening for radar.
Once the radar check is complete the 5 GHz radio on channel 136 will become operational but by that time clients would have roamed to the 2.4 GHz radio. Configuration changes that affect the radios will cause the radar check to performed again and so clients will again roam to the 2.4 GHz radio.
