Read on SmallNetBuilder
Last edited:
Wi-Fi Roaming Secrets Revealed - Part 4
- Thread starter thiggins
- Start date
Read on SmallNetBuilder
Razor512
Very Senior Member
I wonder, for the disassociate events, can't the AP simply ignore connection requests for a limited time after attempting to move a client device? For example, if it forces a device to disconnect from AP 1, in an attempt to get it to connect to AP2, can it perform the disconnect and just prevent it from connecting back, leaving AP2 to be the only choice?
Also on the 802.11v side of things, Why can't device makers issue a driver update that makes it so that actually considers the request frames sent by the AP? It just seems weird that we still have wireless clients that can clearly see that there is a stronger AP available, but it will choose to fight against attempts of the weaker AP to get the client to move to the stronger AP.
With all of the challenges wireless communications face, it seems strange that roaming is such a long running issue, it is almost like dealing with someone who is complaining that their hand it hot, and continues to do so while others around them shouts at the person to remove his or her hand from the stove, but the person ignores and continues to complain.
Also on the 802.11v side of things, Why can't device makers issue a driver update that makes it so that actually considers the request frames sent by the AP? It just seems weird that we still have wireless clients that can clearly see that there is a stronger AP available, but it will choose to fight against attempts of the weaker AP to get the client to move to the stronger AP.
With all of the challenges wireless communications face, it seems strange that roaming is such a long running issue, it is almost like dealing with someone who is complaining that their hand it hot, and continues to do so while others around them shouts at the person to remove his or her hand from the stove, but the person ignores and continues to complain.
Sineira
Occasional Visitor
Thanks, this is awesome!
On that note, my router died and I had to go buy one urgently. Ended up with a Netgear X10.
It does seem to band steer. When I go to a 5GHz low SS location my iPhone goes to the 2.4 band and when I walk back it moves over to 5GHz. Haven't traced it.
On that note, my router died and I had to go buy one urgently. Ended up with a Netgear X10.
It does seem to band steer. When I go to a 5GHz low SS location my iPhone goes to the 2.4 band and when I walk back it moves over to 5GHz. Haven't traced it.
Witholding responses to probes and association requests is one method of influencing STA behavior. However, I did not see this, at least not for the intial association. The ipod Touch always probed first on 2.4 and sometimes did not probe 5 GHz until after it associated with 2.4.
The downside is that if an AP just refuses to associate a device on a certain band, the STA might not connect at all and the router/AP will be blamed.
I wouldn't say it doesn't work. But these tests found no evidence of it aside from the repeated deauths in the Orbi test.
I'd like to see your take on the Plume Superpods, both for roaming and other characteristics, as they got a rave review from ArsTechnica and others. I was disappointed to see some oddball systems in this comparison, but no mention of Eero. I love reading your reviews, they are by far the most thorough that I've found about Wi-Fi products on the internet, but your choice of devices recently has been sort of bizarre. As far as I can see, Velop, Eero, and now Plume are really the three to look at in the mesh space these days (Orbi not being an actual mesh product).
Orbi, Velop and Google WiFi are top selling WiFi systems, mesh or not. The TP-Link product was included because it's the only one to support 11r. ASUS Lyra was included because of all the ASUS fans that hang around here.
Plume says they have no samples for SNB, so I need to order some to test. eero didn't leave their samples with us.
The focus of the article was roaming performance. I chose mesh systems vs. multi-AP because more consumers buy them and because I had them on hand.
Plume says they have no samples for SNB, so I need to order some to test. eero didn't leave their samples with us.
The focus of the article was roaming performance. I chose mesh systems vs. multi-AP because more consumers buy them and because I had them on hand.
Orbi sells well, but is very limited in not being a mesh system (even though they market it as such). Google WiFi is cheap, it's not fast, anyone who really wants performance isn't going to consider it. It also can't work with another router (bridge mode), so it's very limited in application. I'm an ASUS fan, but if I went to mesh, I would NOT be considering ASUS from everything I've heard. Multiple APs with wired backhaul, separately configured? Sure. Single router? Likely. Not mesh.
That's too bad. If you can convince them to send you some, I'd be very interested to see your take on them. Ars seems to love them. They currently lack the ability to do wired backhaul, however, which seems to be an artifact in their software from when they only had one Ethernet port. Not sure where you're located, but if you have Comcast, your take on their router and Plume-based system would be interesting too. That's a really weird combo, as they have the older Plume pods that are low-power mixed with their flagship high-power XB6 gigabit router.
Fair enough. It doesn't seem like you had one clear conclusion from your testing, which, in and of itself is a conclusion of sorts about Wi-Fi roaming.
Two key points:
1) None of the products were able to band steer the Apple STA.
2) Most products dropped connection for multiple seconds during the roam.
sfx2000
Part of the Furniture
Tim - just wanted to mention that the amount of preparation and effort expended here is well beyond what many other sites are willing to put in.
11k/v/r, as adjuncts of the primary 802.11 a/b/g/n/ac specs, it takes quite a bit of insight and study to even get a hint that it's supported down at the packet level. Where it gets even more complicated is that there are proprietary means as well, and those are not covered in the standards directly. For example, 802.11r vs. Opportunistic Key Caching when one is using WPA2-Enterprise with Radius. Hint, for 11r, it's best tested with WPA2-Enterprise, as the WPA2-Personal is a lot easier - I've seen some AP's that only do 11r with Enterprise...
It is the feature articles and series like this one that sets SmallNetBuilder above and beyond many other tech oriented sites.
Well Done!
sfx2000
Part of the Furniture
Interesting - wonder if there's any Cisco magic going on there - Apple has worked close with them for the enterprise...
Thanks for the kind words, SFX.
The last page of the article was updated with a guess about this. The iPod Touch advertises support for only 2.4 GHz channels in its association and reassociation requests. This could be why all the Wi-Fi systems tested did not attempt to band steer it even though the STA did probe on both bands.
sfx2000
Part of the Furniture
Not entirely accurate - see below - captured from iPod Touch 6G with AP Extreme as the target AP. The stanza below is from the association request message (same thing plays out with Probe Request, and Reassociation as well)
Op mode is 5GHz, AP is set for common SSID (two AP's actually in play - CH1 for both, CH52 and Ch149 for 5GHz support
Code:
Tag: Supported Channels
Tag Number: Supported Channels (36)
Tag length: 10
Supported Channels Set #1 First: 36, Range: 4
First Supported Channel: 36
Supported Channel Range: 4
Supported Channels Set #2 First: 52, Range: 4
First Supported Channel: 52
Supported Channel Range: 4
Supported Channels Set #3 First: 100, Range: 12
First Supported Channel: 100
Supported Channel Range: 12
Supported Channels Set #4 First: 149, Range: 4
First Supported Channel: 149
Supported Channel Range: 4
Supported Channels Set #5 First: 165, Range: 1
First Supported Channel: 165
Supported Channel Range: 1Apple in the Assoc/Reassoc requests advertises support for the band that it is currently in...
My STA was associated to 2.4 GHz. So that would match your assertion. The question is what is the behavior supposed to be.
802.-11-2016 says:
9.4.2.18 Supported Channels element
The Supported Channels element contains a list of channel subbands (from those channels defined in 17.3.8.4.3) in which a STA is capable of operating.
The Supported Channels element is included in Association Request frames, as described in 9.3.3.6; Reassociation Request frames, as described in 9.3.3.8; and Mesh Peering Open frame, as described in 9.6.16.2.2. The use of the Supported Channels element is described in 11.9.2 and 11.9.8. Both these relate to DFS
So supported channels seem to be relevant primarly for DFS operation.
Quick survey of supported channels shown in association/reassociation frames from some captures I've done:
- Apple iPod Touch: Shows only channels in band of the association/reassociation request
- iPhone: Same as iPod
- octoScope Pal-245 (dual-band): Channels in both bands
- Samsung Galaxy Tab A (Android): Supported Channels not present
- Intel ac7265/Win10: Shows only channels in band of the association/reassociation request
- Samsung Galaxy 6: Shows only channels in band of the association/reassociation request
Question still stands as to why none of the mesh systems attempted to roam the iPod. It probed on both bands and got probe responses.
sfx2000
Part of the Furniture
Take a closer look at the action frames between the client and AP - they can be very informative...
In my example above - just after the association, there was an action message with a neighbor report showing the other members (BSSID, Channel Number, etc) of the ESS - and that informative to the client station as it minimizes the search for candidates, and it can make decisions based on that info.
I'll have to dig out my copy of 802.11-2016 and study up a bit - with the channel lists in the management messages - I believe there's a bit of latitude on the implementation.
In my example above - just after the association, there was an action message with a neighbor report showing the other members (BSSID, Channel Number, etc) of the ESS - and that informative to the client station as it minimizes the search for candidates, and it can make decisions based on that info.
I'll have to dig out my copy of 802.11-2016 and study up a bit - with the channel lists in the management messages - I believe there's a bit of latitude on the implementation.
sfx2000
Part of the Furniture
Hmm.. starting to think this is an artifact of the Broadcom/Cypress firmware (in linux speak - brcmfmac)...
RPi3 (not plus, so single band) - associating to an Asus RT-AC68U...
Code:
Tag: Power Capability Min: 3, Max: 21
Tag Number: Power Capability (33)
Tag length: 2
Minimum Transmit Power: 3
Maximum Transmit Power: 21
Tag: Supported Channels
Tag Number: Supported Channels (36)
Tag length: 2
Supported Channels Set #1 First: 1, Range: 11
First Supported Channel: 1
Supported Channel Range: 11I don't think this is a "tell" for band steering on the Association Request/Response handset - it's informative to the AP perhaps, but once connected, one still has to look at the Action Messages to get a real feel for what's going on between the AP and the client.
Driver info on the Pi3...
Code:
Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.39 Inc Compiler: 1.29.4 Inc ClmImport: 1.36.3 Creation: 2017-10-23 03:47:14The Asus RT-AC68U, this is a well known device - running @RMerlin build 384.6 for that device...
Digging deeper - and this is similar to my findings earlier this morning...
RPi 3+ - behaves same as iPod6g....
Code:
Tag: Power Capability Min: 3, Max: -32
Tag Number: Power Capability (33)
Tag length: 2
Minimum Transmit Power: 3
Maximum Transmit Power: -32
Tag: Supported Channels
Tag Number: Supported Channels (36)
Tag length: 10
Supported Channels Set #1 First: 36, Range: 4
First Supported Channel: 36
Supported Channel Range: 4
Supported Channels Set #2 First: 52, Range: 4
First Supported Channel: 52
Supported Channel Range: 4
Supported Channels Set #3 First: 100, Range: 12
First Supported Channel: 100
Supported Channel Range: 12
Supported Channels Set #4 First: 149, Range: 4
First Supported Channel: 149
Supported Channel Range: 4
Supported Channels Set #5 First: 165, Range: 1
First Supported Channel: 165
Supported Channel Range: 1The channel list is not a "tell" for band steering - it's a part of a larger context.
What really interesting is this exchange... and no, I really don't mind the MAC addrs or the SSID's - I've got good security - hack me if you must.
Back on target...
From the client - "tell me about the SSID I'm associated with..." -- it's action message from client to AP
Code:
IEEE 802.11 wireless LAN
Fixed parameters
Category code: Radio Measurement (5)
Action code: Neighbor Report Request (4)
Dialog token: 1
Tagged parameters (15 bytes)
Tag: SSID parameter set: deepthought-w
Tag Number: SSID parameter set (0)
Tag length: 13
SSID: deepthought-wThis is an action message back to the client from the AP - advising a client of the ESS topology... this is basically a candidate list for the client to make some decisions for handoff (or not) - the ESS/BSS is implied, as the client already is associated.
Note that the AP is responding with neighbors based on the power capability in the first trace, no sense wasting time on AP's below the RSSI threshold for a potential handoff...
(sidebar - this is fun stuff, like CDMA and PSMM's when the phone is searching for cells and candidates)
Code:
IEEE 802.11 wireless LAN
Fixed parameters
Category code: Radio Measurement (5)
Action code: Neighbor Report Response (5)
Dialog token: 1
Tagged parameters (45 bytes)
Tag: Neighbor Report
Tag Number: Neighbor Report (52)
Tag length: 13
BSSID: Apple_ee:a2:5e (80:ea:96:ee:a2:5e)
BSSID Information: 0x00000886
.... .... .... .... .... .... .... ..10 = AP Reachability: Unknown (0x2)
.... .... .... .... .... .... .... .1.. = Security: True
.... .... .... .... .... .... .... 0... = Key Scope: False
.... .... .... .... .... ..00 1000 .... = Capability: 0x08
.... .... .... .... .... .... ...0 .... = Spectrum Management: False
.... .... .... .... .... .... ..0. .... = QoS: False
.... .... .... .... .... .... .0.. .... = APSD: False
.... .... .... .... .... .... 1... .... = Radio Measurement: True
.... .... .... .... .... ...0 .... .... = Delayed Block Ack: False
.... .... .... .... .... ..0. .... .... = Immediate Block Ack: False
.... .... .... .... .... .0.. .... .... = Mobility Domain: False
.... .... .... .... .... 1... .... .... = High Throughput Control (+HTC): True
.... .... .... .... ...0 .... .... .... = Very High Throughput (+VHT): False
.... .... .... .... ..0. .... .... .... = Fine Timing Measurement (FTM): False
.... .... .... .... .0.. .... .... .... = High Efficiency (HE AP): False
.... .... .... .... 0... .... .... .... = Extended Range BSS: False
0000 0000 0000 0000 .... .... .... .... = Reserved: 0x0000
Operating Class: 81
Channel Number: 1 (iterative measurements on that Channel Number)
PHY Type: 0x07
Tag: Neighbor Report
Tag Number: Neighbor Report (52)
Tag length: 13
BSSID: Apple_ee:a2:5f (80:ea:96:ee:a2:5f)
BSSID Information: 0x00001086
.... .... .... .... .... .... .... ..10 = AP Reachability: Unknown (0x2)
.... .... .... .... .... .... .... .1.. = Security: True
.... .... .... .... .... .... .... 0... = Key Scope: False
.... .... .... .... .... ..00 1000 .... = Capability: 0x08
.... .... .... .... .... .... ...0 .... = Spectrum Management: False
.... .... .... .... .... .... ..0. .... = QoS: False
.... .... .... .... .... .... .0.. .... = APSD: False
.... .... .... .... .... .... 1... .... = Radio Measurement: True
.... .... .... .... .... ...0 .... .... = Delayed Block Ack: False
.... .... .... .... .... ..0. .... .... = Immediate Block Ack: False
.... .... .... .... .... .0.. .... .... = Mobility Domain: False
.... .... .... .... .... 0... .... .... = High Throughput Control (+HTC): False
.... .... .... .... ...1 .... .... .... = Very High Throughput (+VHT): True
.... .... .... .... ..0. .... .... .... = Fine Timing Measurement (FTM): False
.... .... .... .... .0.. .... .... .... = High Efficiency (HE AP): False
.... .... .... .... 0... .... .... .... = Extended Range BSS: False
0000 0000 0000 0000 .... .... .... .... = Reserved: 0x0000
Operating Class: 128
Channel Number: 52 (iterative measurements on that Channel Number)
PHY Type: 0x09
Tag: Neighbor Report
Tag Number: Neighbor Report (52)
Tag length: 13
BSSID: Apple_1e:57:3e (90:72:40:1e:57:3e)
BSSID Information: 0x00000886
.... .... .... .... .... .... .... ..10 = AP Reachability: Unknown (0x2)
.... .... .... .... .... .... .... .1.. = Security: True
.... .... .... .... .... .... .... 0... = Key Scope: False
.... .... .... .... .... ..00 1000 .... = Capability: 0x08
.... .... .... .... .... .... ...0 .... = Spectrum Management: False
.... .... .... .... .... .... ..0. .... = QoS: False
.... .... .... .... .... .... .0.. .... = APSD: False
.... .... .... .... .... .... 1... .... = Radio Measurement: True
.... .... .... .... .... ...0 .... .... = Delayed Block Ack: False
.... .... .... .... .... ..0. .... .... = Immediate Block Ack: False
.... .... .... .... .... .0.. .... .... = Mobility Domain: False
.... .... .... .... .... 1... .... .... = High Throughput Control (+HTC): True
.... .... .... .... ...0 .... .... .... = Very High Throughput (+VHT): False
.... .... .... .... ..0. .... .... .... = Fine Timing Measurement (FTM): False
.... .... .... .... .0.. .... .... .... = High Efficiency (HE AP): False
.... .... .... .... 0... .... .... .... = Extended Range BSS: False
0000 0000 0000 0000 .... .... .... .... = Reserved: 0x0000
Operating Class: 81
Channel Number: 1 (iterative measurements on that Channel Number)
PHY Type: 0x07Thought this might be interesting... action messages are really important when looking at roaming...
Last edited:
sfx2000
Part of the Furniture
I'm not challenging the findings here -- far from that - it's an interesting problem at the moment, and a really hard one...
I'm starting to think that much of the consumer gear, while they might suggest k/v/r support, they actually don't, because they can't - they try to some degree, brute forcing clients, and hope and pray for the client to "do the right thing" - without having the PCAP's used for testing in this series of articles, it's really hard to tell.
The results are telling however - to get good roaming - it's not consumer gear. Seriously, it's not.
The clients are more significant in the consumer space - some do better than others...
But to get serious roaming across an ESS, esp. a multiple AP ESS, it does take a lot of work - enterprise grade WLC's and AP's have problems here even with roaming. Even there, many vendors make claims, but the only vendor that I've seen first hand pull it off successfully is Cisco, and that was in a WPA2-Enterprise configuration. I've seen logs and evidence that Aruba and Ruckus can do it, but that's second hand info for me. The logs tell me it's true...
Roaming for WiFi - the WLC has situational awareness of all the clients, and all the AP's - available capacity, the network loading loading across different traffic streams and QoS aspects - and there, it's still very client dependent.
"seamless" roaming - that's a lot to ask from consumer gear that one can pull off the shelf, put on a table, and plug it in.
It's kind of more 3D-TV for WiFi - MU-MIMO, 160MHz, you name it - checks on a box on the shelf.
sfx2000
Part of the Furniture
BTW - the above list is a really good point about client capability and roaming - you touched on this many times in the article series, but it's good to re-iterate this one item.
No matter what the AP's might claim - the client really does matter here with roaming
Similar threads
