Wireless Access

AOS 8.6.0.5

Hello,

Could someone tell me what happens when a client is steered from one radio to another on the same AP please? ie what is the process, is there a re-auth, etc?

(For reference this is in response to a user reporting that their device was connected to one of our SSIDs with no internet for a long time (apparently 'obtaining IP address'), but eventually it did connect, and the connection time coincides with a band steer on that client, so I'm wondering how a band steer might have prompted the connection to complete).

P.S. - I am seeing the band steer events on AirWave, I assume this is actually something to do with Client Match rather than the the Steering Mode setting in the VAP, I read that if ClientMatch is turned on then Band Steering doesn't take place?

Thank you,

Guy

Hi, 

band steering "pushes" de device to a better radio (tipically 5 GHz) and it does not mean to disconnect the device. By anyway the device is the one that have the last word.

Check this link about AirMatch and Band Steering and check for cjoseph comments

JoseMi

Hello,

Thanks for this. So according to that thread band steering should not be being used, but AirWave reports that it is - I wonder if that is just some sort of legacy textual description in the AirWave code, or whether it doesn't relate to the band steering setting on the VAP at all.

I'm just trying to work out whether the fact that the client device managed to connect at the same time as the band steer event happened is coincidental, or whether it has some significance. The client device must disconnect from the 2.4 radio and reconnect to the 5GHz radio, so there must be a process involved there, I wanted to find out exactly what that process is.

Guy

Try this command on the MM:

show ap arm client-match history client-mac <mac address of client>

That will give you a history of what happened with that client.

Thanks Colin,

This looks really useful, thanks. I just ran it and it gave me what looks like a possibly interesting result on the client device in question (unfortunately we don't have control over the device so I can't say what its status is or was):

Time of Change Station Reason Status/Roam Time/Mode Signal(S/T/A/As) Band(S/T/A) Radio Bssid(S/T/A) AP Name(S/T/A)
-------------- ------- ------ --------------------- ---------------- ----------- ------------------ --------------
2020-08-24 19:36:51 c0:ee:fb:91:67:a1 Sticky Too-Long/3693/Deauth -79/-63/-91/-77 5G/5G/2.4G 6c:f3:7f:82:b8:18/00:4e:35:6d:5b:50/00:4e:35:6d:4e:40 6c:f3:7f:c0:2b:81/20:4c:03:5a:3d:a2/20:4c:03:5a:41:12
2020-08-24 18:34:57 c0:ee:fb:91:67:a1 Sticky No-Move/10/BTM-TO -79/-63/-79/-81 5G/5G/5G 6c:f3:7f:82:b8:18/00:4e:35:6d:5b:50/6c:f3:7f:82:b8:18 6c:f3:7f:c0:2b:81/20:4c:03:5a:3d:a2/6c:f3:7f:c0:2b:81

...<snip>

The "Sticky Too-Long/3693/Deauth" looks interesting, could that 3693secs indicate a period where the client was not roaming I wonder?

I'll try to get the owner of the device to contact us when they are having issues so that we can try to get some live information.

"sticky" means that the infrastructure thinks that client should be on a better AP.  Too long means when it tried to move the client, it took too long to end up on the new AP.  It is possible that the client already left the building, so the deauth move would not have any effect on the client.

Quite frankly, client match moves are just suggestions to a client to move to a better AP or band.  They can fail pretty regularly for highly mobile client that might not see or ignore deauths.  Clients that support 802.11v have much better success with client match moves.   Most times it is not worth chasing down clients that have failures...  It is more a troubleshooting tool to piece together what might have happened.

Ok thank you - as you say it's still useful to help put the jigsaw together. I will ask the device owner to contact us next time they have this roaming issue and we can look at it happening live, but essentially it's probably a client issue so we probably can't do much to help them. It's a reasonably modern device (OnePlus 6 (A6003) - Android 10).

We have seen on various forums that other owners have had roaming problems but it's probably true that you can find someone complaining about pretty much anything for any given device somewhere!

Thanks again

I can't add any more suggestions and knowledge that CJoseph hasn't already, however, if you want to see the logic of ClientMatch, you can go to www.westcott-consulting.com and download the ArubaOS 8 files. They are free to anybody. The download includes 6 flowcharts that describe the different ClientMatch processes along with the logic as to whether an attempt will be made to move the client. The client move logic is also there. The overview flowchart will help you understand the order process of the other flowcharts.