05-10-2020 05:29 AM
Hello community,
I am convinced that there is some method to check out the client roaming time.
Suggest please
Aviv
Solved! Go to Solution.
05-11-2020 03:21 PM
Aviv,
Finding a way to determine the time a roaming event can be a little subjective in that it depends on when YOU determine the point at which point the roam event actually starts. (Some might say that the roam begins with the client starts probing the new AP, but doing so means you are including the time that it takes for the client to probe for APs and get responses. Do you care about that?).
For someone who is more concerned about actual delays between roams for data/time sensitive applications, maybe your timer begins when the last data frame is sent by the client (ACK’d also maybe?) and stops when the client sends its first data frame using the new AP.
Specifying when the roam event events is usually easier. Usually it’s the end of the 4-way handshake (signifying the end of the association process with the new AP) or when the client first sends a data frame when using the new AP that it roamed to.
Personally, I would START the ‘timer’ when the authentication request frame is seen from the client that is roaming and would then END the timer when message-4 of the 4-way handshake is transmitted by the AP.
So in the messages you posted, it looks like you would start at the first “AUTH” message from the client...which SHOULD be the authentication request.
From the messages you posted though, I don’t see the 4-way handshake messages.
Use this filtered syntax to only show what we’re looking for here.
#remote-debug wireless rf-domain <RFD> clients all events management wpa-wpa2
A roam should look similar to this.
05-13-2020 05:31 AM
Hello Chris,
Very informative.
Thanks a lot
Aviv
05-11-2020 03:21 PM
Aviv,
Finding a way to determine the time a roaming event can be a little subjective in that it depends on when YOU determine the point at which point the roam event actually starts. (Some might say that the roam begins with the client starts probing the new AP, but doing so means you are including the time that it takes for the client to probe for APs and get responses. Do you care about that?).
For someone who is more concerned about actual delays between roams for data/time sensitive applications, maybe your timer begins when the last data frame is sent by the client (ACK’d also maybe?) and stops when the client sends its first data frame using the new AP.
Specifying when the roam event events is usually easier. Usually it’s the end of the 4-way handshake (signifying the end of the association process with the new AP) or when the client first sends a data frame when using the new AP that it roamed to.
Personally, I would START the ‘timer’ when the authentication request frame is seen from the client that is roaming and would then END the timer when message-4 of the 4-way handshake is transmitted by the AP.
So in the messages you posted, it looks like you would start at the first “AUTH” message from the client...which SHOULD be the authentication request.
From the messages you posted though, I don’t see the 4-way handshake messages.
Use this filtered syntax to only show what we’re looking for here.
#remote-debug wireless rf-domain <RFD> clients all events management wpa-wpa2
A roam should look similar to this.
05-11-2020 02:13 PM
Hello Chris,
There is several kinds of messages from the filtered results:
I ACTION
O ACTION
I AUTH
O AUTH
I REASSOC_REQ
O REASSOC_RESP
I ACTION
O ACTION
In which conditions I typically should see any of these messages?
What exactly is the start and the end point of the roaming procedure ?
Thanks
Aviv
05-11-2020 01:31 PM
Aviv,
More specifically, the command I use for watching roaming clients are these two. You can optionally fine-tune what you are capturing with additional filter syntax.
#remote-debug wireless rf-domain <rfd> clients <MAC> events management
(Filter out Probe request frames)
#service pktcap on radio all count 9999 filter not dot11 probe and dot11 mgmt and ether host <MAC>