Wi-Fi Roaming Secrets Revealed - Part 4

[sfx2000]

So supported channels seem to be relevant primarly for DFS operation.

It's a larger context - not really DFS, checked up on that.

If an AP is active in DFS space, it's already passed the test there. The client can always say - "I support this", but active scans must obey DFS rules, passive scan might observe an AP operating in DFS space.

Real world example here.... client can find CH52 if CH52 is already active as an AP.

Rpi3Plus -- iw list...

Frequencies:
            * 5180 MHz [36] (20.0 dBm)
            * 5200 MHz [40] (20.0 dBm)
            * 5220 MHz [44] (20.0 dBm)
            * 5240 MHz [48] (20.0 dBm)
            * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
            * 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
            * 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
            * 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
            * 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
            * 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
            * 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
            * 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
            * 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
            * 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
            * 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
            * 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
            * 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
            * 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
            * 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
            * 5720 MHz [144] (20.0 dBm) (no IR, radar detection)
            * 5745 MHz [149] (20.0 dBm)
            * 5765 MHz [153] (20.0 dBm)
            * 5785 MHz [157] (20.0 dBm)
            * 5805 MHz [161] (20.0 dBm)
            * 5825 MHz [165] (20.0 dBm)

[/code]

Intel 7265 - Ubuntu 18.04LTS - the intel driver under linux is always good...

Frequencies:
* 5180 MHz [36] (22.0 dBm)
* 5200 MHz [40] (22.0 dBm)
* 5220 MHz [44] (22.0 dBm)
* 5240 MHz [48] (22.0 dBm)
* 5260 MHz [52] (22.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (22.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (22.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (22.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (22.0 dBm) (no IR, radar detection)
* 5520 MHz [104] (22.0 dBm) (no IR, radar detection)
* 5540 MHz [108] (22.0 dBm) (no IR, radar detection)
* 5560 MHz [112] (22.0 dBm) (no IR, radar detection)
* 5580 MHz [116] (22.0 dBm) (no IR, radar detection)
* 5600 MHz [120] (22.0 dBm) (no IR, radar detection)
* 5620 MHz [124] (22.0 dBm) (no IR, radar detection)
* 5640 MHz [128] (22.0 dBm) (no IR, radar detection)
* 5660 MHz [132] (22.0 dBm) (no IR, radar detection)
* 5680 MHz [136] (22.0 dBm) (no IR, radar detection)
* 5700 MHz [140] (22.0 dBm) (no IR, radar detection)
* 5720 MHz [144] (22.0 dBm) (no IR, radar detection)
* 5745 MHz [149] (22.0 dBm)
* 5765 MHz [153] (22.0 dBm)
* 5785 MHz [157] (22.0 dBm)
* 5805 MHz [161] (22.0 dBm)
* 5825 MHz [165] (22.0 dBm)

So I don't think DFS has anything to do here from a client perspective - "no IR" means just that the client must also pass the test when searching for an AP.

That being said - on a passive search - it assumes the AP has already passed the DFS tests, so it can actively probe the AP on those channels.

Roaming is fun - DFS is interesting for other reasons.

 

[thiggins]

If you want to see this stuff in action, check out my presentation at an octoScope seminar in July.

 

[sfx2000]

If you want to see this stuff in action, check out my presentation at an octoScope seminar in July.

Nice presentation - and good to put a face to the name...

Digging around - stumbled on this nice little doc from Ci$co - 802.11r, 802.11k, 802.11v, 802.11w Fast Transition Roaming

(warning - pdf link) - pretty much backs up the Wifi roaming series in a Cisco context, and is good backup for the conversation on the thread here.

 

[coxhaus]

Nice Cisco doc. Goes to show there is a lot of knowledge behind Cisco's hardware. This is part of the reason I run Cisco gear. I have been using Cisco's roaming for years.

 

[sfx2000]

Nice Cisco doc. Goes to show there is a lot of knowledge behind Cisco's hardware. This is part of the reason I run Cisco gear. I have been using Cisco's roaming for years.

Cisco always had decent roaming within their silo - even back in the old days of 11 a/b/g - all proprietary, but it worked - even with enterprise level auth that was there at the time. The doc that I linked - good discussion on the Standards based stuff - which is relevant to the thread and the article series.

@thiggins - I really did enjoy the presentation video, and you covered things there that had more emphasis than you did on the site articles. A suggestion would be to condense them into one, and update some of the things you related during the presentation.

 

[sfx2000]

@thiggins - One of the issues I've observed with the Orbi's and Roaming - this applies towards the 802.11k stuff, which clients can make some decisions on...

Let's look a a couple of params...

802.11k Information Elements (IEs) Clients send requests for neighbor lists only after they associate with the APs that advertise the RM capability Information Element (IE) in the beacon.

The following elements are implemented in the beacon and probe response on the AP to ensure smooth integration with Apple handheld devices:

• Country Element—The Country Information Element contains the information required to allow a station to identify the regulatory domain in which the station is located and to configure its PHY for operation in that regulatory domain.
• Power Constraint Element—The power constraint element contains the information necessary to allow a client to determine the local maximum transmit power in the current channel.
• RM Enable Capabilities Element—The RM Capabilities element is five octets long. When this element is included in a beacon or probe response, it uses bit 1 to signal so that the AP can provide neighbor list. When used in an association request, bit 1 signifies the client's request for a neighbor list. The presence of all three of these IEs signifies that this SSID is configured to provide a neighbor list on request. For this release we send neighbor list based on the request from the client and not on the neighbor list capability of the client in the IE.

That being said - here's what Orbi does, and @thiggins - this might be why you don't see any band steering...

Orbi says we're 127dBm, and no power constraint... which can be a bit of a problem

In 2.4GHz - the Orbi says this...

Country: US Environment: Indoor/Outdoor
Channels [1 - 11] @ 127 dBm

For 5Ghz - on the Client facing side...

        Country: US     Environment: Indoor/Outdoor
                Channels [36 - 36] @ 127 dBm
                Channels [40 - 40] @ 127 dBm
                Channels [44 - 44] @ 127 dBm
                Channels [48 - 48] @ 127 dBm
                Channels [52 - 52] @ 127 dBm
                Channels [56 - 56] @ 127 dBm
                Channels [60 - 60] @ 127 dBm
                Channels [64 - 64] @ 127 dBm

This, imho, is actually a bug in the Orbi software - the numbers there should reflect reality... netgear should fix this - it'll lead to a bit better user experience.

And perhaps impacted your testing for this series of articles...

 

[sfx2000]

Regarding Orbi - this is what one would expect...

(below was grabbed from a Netgear Residential Gateway - e.g. CPE)

        Country: US     Environment: Indoor/Outdoor
                Channels [1 - 11] @ 30 dBm


        Country: US     Environment: Indoor/Outdoor
                Channels [36 - 36] @ 30 dBm
                Channels [40 - 40] @ 30 dBm
                Channels [44 - 44] @ 30 dBm
                Channels [48 - 48] @ 30 dBm
                Channels [52 - 52] @ 24 dBm
                Channels [56 - 56] @ 24 dBm
                Channels [60 - 60] @ 24 dBm
                Channels [64 - 64] @ 24 dBm
                Channels [100 - 100] @ 24 dBm
                Channels [104 - 104] @ 24 dBm
                Channels [108 - 108] @ 24 dBm
                Channels [112 - 112] @ 24 dBm
                Channels [116 - 116] @ 24 dBm
                Channels [120 - 120] @ 24 dBm
                Channels [124 - 124] @ 24 dBm
                Channels [128 - 128] @ 24 dBm
                Channels [132 - 132] @ 24 dBm
                Channels [136 - 136] @ 24 dBm
                Channels [140 - 140] @ 24 dBm
                Channels [149 - 149] @ 30 dBm
                Channels [153 - 153] @ 30 dBm
                Channels [157 - 157] @ 30 dBm
                Channels [161 - 161] @ 30 dBm
                Channels [165 - 165] @ 30 dBm

 

[tannebil]

.... 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...
.

The Plume wired backhaul limitation only exists if you want to use router mode. No restriction in bridge mode. I run all four of mine (a mix of V1a nd V2 pods) with wired backhaul.

One of the reasons I didn’t move to the Comcast version was of the restriction to wireless only but I suspect for Comcast’s purpose, it’s not a big issue. Running with wireless backhaul would provide perfectly accepable performance in 95% of their installs. Where people want reliability, low latency, and decent roaming more than raw performance.

I don’t feel any performance difference between the V1 and V2 pods. I can see it when I test for it but I don’t feel it in normal use with my 300Mbps Comcast service. Partially because 95% of my time is using 2x2 clients and partially because I don’t do many things where more than say, 100Mbps, is noticeable. Your uses may be different of course.

My theory is that the V2 pods might actually mean a worse roaming experience but I lack the tools, process, and drive needed to actually test it. My reasoning is that in a V1 environment, when I move a couple of rooms, it’s more likely that I’ll move out of range of the current V1 pod so the client will decide to roam and the closest pod will be in the new room. With fewer, more powerful V2 pods, I’ll have to more farther before the client decides to roam. Sounds good to me on paper but I’m not sure I’d bet money on it. I switched from five V1 pods to two V2/two V1 pods and can’t tell any difference so far (except with my 3x3 MBP sitting in the same room with a V2 pod). Huge caveat is that they are all wired. If I didn’t fear my wife’s wrath, I’d switch to wireless backhaul and see what the experience was like.

 

[DaDaniel]

Would it be possible to expand this roaming test to two or more pieces of non-Mesh Hardware like TP-Link EAP225 or Ubiquiti UniFi as they claim to have roaming support in the last firmware version?

 

[thiggins]

Would it be possible to expand this roaming test to two or more pieces of non-Mesh Hardware like TP-Link EAP225 or Ubiquiti UniFi as they claim to have roaming support in the last firmware version?

Sorry, but no. Too many other things to test.

 

[BiggAW]

The Plume wired backhaul limitation only exists if you want to use router mode. No restriction in bridge mode. I run all four of mine (a mix of V1a nd V2 pods) with wired backhaul.

One of the reasons I didn’t move to the Comcast version was of the restriction to wireless only but I suspect for Comcast’s purpose, it’s not a big issue. Running with wireless backhaul would provide perfectly accepable performance in 95% of their installs. Where people want reliability, low latency, and decent roaming more than raw performance.

I don’t feel any performance difference between the V1 and V2 pods. I can see it when I test for it but I don’t feel it in normal use with my 300Mbps Comcast service. Partially because 95% of my time is using 2x2 clients and partially because I don’t do many things where more than say, 100Mbps, is noticeable. Your uses may be different of course.

My theory is that the V2 pods might actually mean a worse roaming experience but I lack the tools, process, and drive needed to actually test it. My reasoning is that in a V1 environment, when I move a couple of rooms, it’s more likely that I’ll move out of range of the current V1 pod so the client will decide to roam and the closest pod will be in the new room. With fewer, more powerful V2 pods, I’ll have to more farther before the client decides to roam. Sounds good to me on paper but I’m not sure I’d bet money on it. I switched from five V1 pods to two V2/two V1 pods and can’t tell any difference so far (except with my 3x3 MBP sitting in the same room with a V2 pod). Huge caveat is that they are all wired. If I didn’t fear my wife’s wrath, I’d switch to wireless backhaul and see what the experience was like.

This is true. That's why I think it's an artifact of the old single-port Plume Pods, as they only had one port. Hopefully that will be fixed in a future update, as having the Plume Pods as the router would be ideal for someone like myself to set up a network for someone who is less tech savvy and needs something easy to manage. At the point that there is a separate router, modem, and Plume Pod network, it's not that much more complicated just to use individual routers as APs and have them all separately managed with separate IP addresses as I typically do now. Separately managed routers are about half the price of Plume or Eero for the same square footage, so when wired backhaul is present, there has to be a really good value proposition for switching to a centrally managed system.

Unfortunately, Comcast's version seems to limit throughput to roughly 100mbps, which sucks, as they are now bundling 250mbps (provisioned at 302.5mbps) with a lot of their Double- and Triple-play packages, and even if you're internet-only, they force you to get 250mbps down in order to get 10mbps up. The SuperPods would be great for Comcast. The whole Comcast system seems strange to me, since you own the pods, but they only work with a rented router that costs $11/mo. I'm sure they'll sell quite a few of them, but it's really bad deal compared to owning your own equipment. The wireless configuration is just rather interesting given that their routers are high-powered with all the latest bells and whistles and they pair those with the Plume Pods that are small and low-powered. My sense is that they don't want to support wired backhaul, because troubleshooting it would be a nightmare over the phone, and for some reason, as soon as you get beyond one wireless router that has a cable modem in it, or is plugged into one, people's head explode. I've seen it on the TiVo forum with MoCA, people just can't figure out how MoCA work. Same for wireless mesh with wired backhaul, or other "alternative" network technologies or topologies.

Yes, most things don't need more than 100mbps, until you try to pull a huge software update for something, and it can pull 30MBps+ off of Microsoft/Apple/Canonical/etc servers. I think you'd also notice a LOT more difference if you were using wireless backhaul, as then you start to really run into the hardware limitations of the original pods, versus supplying each one with hardwired gigabit backhaul, and only needing that one wireless hop to the device.

That's an interesting theory. I would think that there would always be the same in-between, since you have to place the older pods closer together, since they are lower power, but then again, I'm just musing out loud here as well. When the Superpods have wired backhaul, does the 4x4 radio get used for client connectivity, i.e. allowing the 3x3 MBP to connect at 3x3 on 5ghz and get higher peak speeds?

 

[tannebil]

Plume says both 5Ghz radios are available for clients and backhaul. My MBP shows a PHY connection of up to 1300Mbps which is 3x3 which squares with that claim.

Let’s say I have a low powered AP in every room of my house that provided a great signal in that room, an average signal in the adjoining room, and a weak signal two rooms over. Any time I move at least two rooms away from my current room, my client would want to roam. Imagine an ideal world (for this purpose), where the interior walls in the house actually blocked the signal at the wall. Any time you moved one room, my client would roam. That’s my general reasoning as to why the lower powered V1 might make a better roaming system than the high power (longer range) V2. I think that’s the same general idea as using variable power gear.

Consumer mesh today is just taking baby steps. Placement guidance is laughably primitive and the feedback is equally crude in that it usually only tells you when the intramesh connections are excruciatingly bad. I’ve seen nothing like the microphones used to tune multi-channel sound systems to a room.

Imagine if you had a sensor that integrated with a mesh system where you move it from room to room and the system used the information collected to make AP placement recommendations and then tuned the power levels and beam forms to provide the best solution for the home (recognizing that “best” can mean different things in different situations). How about if the sensors were cheap enough to be permanently placed for continuous optimization or maybe was just software that ran on regular wireless devices occasionally? It could even include information about where Ethernet connections are possible (maybe the sensor has a wired pass-through) so it could make intelligent recommendations between wired and wireless backhaul. Add in automatic collection of sources and sinks data so that it knows which routes to optimize and we are on the way to a really intelligent mesh solution. Right now, we pretty much just scatter the APs around blindly and hope it’s “good enough”. I think Salter’s latest review of AiMesh shows that even the most knowlegable can be surprised at what happens when instincts and experience encounter the real world.

 

[sfx2000]

@thiggins - would be interesting to see bandwidth over time - aligned with handoffs would be nice, but real world client perspective would be very interesting....

Something like this... uplink and downlink - and can color code as need for bands...

 

[Nep☆Gear]

It is notoriously difficult to decide which radio network to connect to when you are roaming. If you jump to another AP because it looks better now, five seconds later you may find it made the wrong choice.

LTE deals with the problem by having base stations very closely coordinated, ideally transmitting and receiving signals to a client from multiple base stations at the same
time. Since you're connected to multiple base stations there isn't the risk of "flapping" between two or three of them. The base station hardware is crazy expensive and takes experts to set it up, however.

In terms of real life performance, the literature (and experience) shows that the occupancy of the network you are connecting to matters more than the hypothetical bandwidth. Remember that most of these tests are for people making fast connections to local servers. That's fine, but most of the time people are connecting to the internet through a slower-than-WiFi link with much more latency. Add just a little contention to the link and the packet loss that comes with it, and you find web pages take a lot longer to load, particularly when you factor in the fact that you're not *adding* the time of connections to determine the time to render the page, but more like taking the *maximum* which gives you a "long tail" distribution of pain.

 

[coxhaus]

The hardest roaming test to pass which is easy to setup that I have found is as follows.
1. 2 APs setup for roaming. You need 2 Apple iPhones.
2. Station an Apple iPhone to where they connect to the 2 separate APs.
3. Call the other iPhone using WiFI calling.
4. Now walk over so the WiFi call has to roam to 1 AP. You need to keep talking as the roaming is happening.
5. If roaming works the conversation will continue normally with no drop outs.