Hello all,
We're troubleshooting some roaming issues at a customer site and the timeline shows this:
What does the Time to Connect indicate? If that's the time needed to roam then it's ridiculously high and way too high for VoWLAN roaming. I cannot imagine this is the roaming time (everything above 150ms should be marked red) because even for data a 4 second roam is way too slow .
This is a SSID with WPA2/PSK encryption and layer 2 roaming so there's no external influence on the roaming speed. I'm accustomed to sub 10ms roaming in Cisco Enterprise with a PSK or 802.1X with .11r enabled.
Can someone clarify that number ?
With kind regards,
Marcel Tempelman.
I think it does mean what you said, here is a report from a Cisco wireless phone roaming about, with plenty of red!! It does though seem a long time, I'll have to go to the site and see if that is the real experience...
Looking at other devices it seems that:
0-5s is green
5-10s is amber
10s or more is red
Interestingly a Wi-Fi security radio on the same SSID fares much better:
Out of curiosity , what MR firmware version are you running ?
These access points are running MR28.5
I think 28.6 fixes some bugs related to PKMID which ''could'' slow association time. That might be worth a try !
We are running 28.6...
@cmr time to connect is the time delay between re-association/association sent by the client and the final acknowledgment sent by the AP. Can we have a support case opened for this issue? We would like to investigate this further and get some more information that we can track internally and fix, if we identify this as a bug.
Any news on ths topic ? I still see 'time to connect' values between 2000-4500ms when roaming. Which is quite bad considering this is on a Voice SSID.I think I'll open a case as well.
Apologies, support did reply and they said that it reflects the time between the roaming starting and the client reporting a successfully completed roam. We found many devices report about what you'd expect with roaming around 100ms but Cisco 8821 phones reported much longer roams. I haven't had a chance to verify that it is just a reporting issue (client or cloud related) yet, but I think that is the issue.
Thanks for the update! This afternoon I'll be going on site and will try to collect some data about roaming (there are issues with a Gigaset android devices) with different devices and see if it corresponds with what the dashboard is telling me.
Yesterday I did some testing with a Android smartphone from Gigaset. These phones are horrible when it comes to roaming. So I made a round with my iPhone 8. If I look at the timeline from a wireless troubleshooting perspective then this is a useless tool. The reporting is not consistent (sometimes the time to connect is missing) and the reported time values are nowhere near what you want to see when checking requirements. For example if you check Voice over WLAN requirements you want to see if the device roams within 150ms. Do not know who developed this but this is developed without any knowledge about wireless troubleshooting.
This is useful information (Cisco Wireless Debug Analyzer):
In terms of timing I think I have figured it out, below I was on a call walking about and had no glitches or drop out - this is shown by the red bracket. Where I was roaming with the phone in standby the roaming is horrible - this is the lower ones. That makes sense as the radio is kind of sleeping in that state.
The Meraki example which I posted was during a MS Teams call from my iPhone 8 (started at 15:16 and took 6 minutes). The call was quite good (some glitches). The experience with the Gigaset smartphone was quite horrible but that's because it's crap hardware (sticking to APs up to -90+ dBm.......). But that aside when I look at the iPhone roaming the number do not make any sense to me. When I look at your example it seems to make sense.
Hi all,
Seeing the same high time to connect values on my network.
Working with Windows CE devices running on 2.4GHz in a Meraki MR36 situation with version 28.6.1
Any clue why I see those high values?
Kind regards,
Maybe the same reason @cmr suspected in a post above? Maybe the device was "sleeping"/inactive at the moment showing in the screenshot and it would be normal behavior. It does seem the device was on the move between at least 3 APs.
Or did the specific client report some trouble and is that an example capturing the trouble moment?
@cmr Are you still seeing Time to connect times > 10000ms ?
I'm running old MR firmware and I'm wondering if it's simply not a display issue since no one is reporting issues on my end.