What's new

Orbi - the bandwidth annihilator

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

sfx2000

Part of the Furniture
Interesting... reviews on the Main Site - Orbi's are the shizzle...

A comment from that review...

When I first got NETGEAR's pitch for Orbi, I expressed concern about its exclusive use of 5 GHz for backhaul. But NETGEAR assured me they had done their homework and that the results would be impressive.

My neighbor just picked up an Orbi system (RBR-50 according to wireless PCAP's)

I'd have to say, not impressed, it blows away all adjacent networks...

Seriously... I'm not an orbi user, but I have an adjacent network to it - so worth a read...

Why I decided to dig into this - I've got a 2.4GHz span to a corner of the house, generally it works, and my DirectTV is also WiFi via a wireless video bridge to the Genies on 5Ghz - Stuff just got weird - things stopped working...

At a high level...it's a mess

2.4GHz - autotunes to Ch 9, with 2 visible SSID's for clients, and a hidden SSID for I guess backhaul

5GHz - client radios are camping on CH 48, with the backhaul on CH 157 - interesting to note that the 5GHz side for the clients are limited to

The 2.4GHz is pretty active across all SSID's (and the hidden), same goes with the 5GHz on two channels, which is impacting all non-DFS channels.

Seriously NETGEAR - check your 2.4GHz auto-tuning algo's - camping on CH9 with Wide Channels and VHT can cause a lot of issues with adjacent overlapping WLAN's - VHT in 2.4GHz can and does cause problems with many legacy clients.

All base and satellites... "all your base belong to us"

maxresdefault-2.jpg


This is is also a concern - all Orbi AP STA's report Max TX as 127 dBm - which is a problem for associated STA's and overlapping WLAN's

2.4GHz info - front and backhaul - remember, this is camping on CH9

Country Info: First Channel Number: 1, Number of Channels: 11, Maximum Transmit Power Level: 127 dBm​

5GHz client AP's - this is seen by the Client STA's - camping on CH48

Country Info: First Channel Number: 36, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 40, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 44, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 48, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 52, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 56, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 60, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 64, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm​

5GHz Backhaul - this is the hidden backhaul SSID on CH157

Country Info: First Channel Number: 100, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 104, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 108, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 112, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 116, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 120, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 124, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 128, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 132, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 136, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 140, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 149, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 153, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 157, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 161, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm
Country Info: First Channel Number: 165, Number of Channels: 1, Maximum Transmit Power Level: 127 dBm​

Note that Orbi is essentially taking up all the non-DFS space, and it's hot... signal strengths observed in both 5GHz channels are higher than my AP's - and it's hogging the 2.4GHz by sitting the primary on CH9 as a wide channel, which also impacts pretty much everything on CH6 and CH11

So Orbi essentially is sucking up 40MHz in 2.4GHz (cross channel at that) and 160 MHz in the 5GHz non-DFS channels

To boot - the Orbi's spam the Beacon channels with Broadcast SSID's - e.g. client behavior looking for associated BSSID's - and this is broad spectrum across all supported channels. and adjacent BSS's respond in kind

this behavior was noted from the sattelite Orbi's to the base - "are you there?" is essentially the action requested...

Challenge here is that every STA within hearing distance responds as per 802.11... so one sees a lot of probe requests and responses...

There's ways to fix things - adjust the Tx messages in the beacon, for 2.4GHz, look at 1/6/11 for NA SKU's, and show the backhaul, and perhaps even share the backhaul with client AP's there.

Orbi is the worst thing since the early Draft 802.11n stuff, IMHO

I haven't had as much of a problem since 2007 with my WLAN...

Orbi is not a friendly neighbor...
 
Last edited:
This is is also a concern - all Orbi AP STA's report Max TX as 127 dBm - which is a problem for associated STA's and overlapping WLAN's
Presumably this is some sort of signed 8-bit field that's been set to "maximum" (0x7F). I doubt that 5000 megawatts is a sensible value.:eek:
 
If you use an Ethernet backhaul for the Orbi, does it allow clients to then connect to the 4 stream radio like how the EX8000 allows it, or does it just shut off that higher performing radio?
It would be good if they can offer all 3 bands available for client devices, with an Ethernet backhaul, as they will avoid unneeded slowdowns while still benefiting from the 802.11k and 802.11v. (sadly they did not add 802.11r support)

As for the transmit power, the Orbi makes for quite a weak AP, with an extremely low transmit power (at least according to the FCC docs), they may need to figure out a way to boost it a bit more (unless they went with amplifiers that have an extremely low maximum gain.

8x3Arma.png
 
As for the transmit power, the Orbi makes for quite a weak AP, with an extremely low transmit power (at least according to the FCC docs), they may need to figure out a way to boost it a bit more (unless they went with amplifiers that have an extremely low maximum gain.

Not by my observations.... something is very wrong here...

Screen Shot 2018-07-15 at 7.52.37 PM.png
 
Seems like the info being sent out is different than what is actually being used. I wonder if it is like where some 3rd party firmware allow you to specify a transmit power but it makes no difference to the real world transmit power.
 
sfx2000 I have complained to NG over multiple betas about using channels other than 1/6/11 especially with them jumping to 40Mhz width on rare occasions in congested neighborhoods (The latter issue they did fix in one product and I didn’t see it since in others). This 1/6/11 issue is not just with Orbi but every product of theirs. In my neighborhood with over 20 APs in detectable range the only ones not on 1/6/11 are the NG products.

To top it off if you have an Arlo base station it will use the same channel as the nearest AP, apparently this supposedly reduces interference with the nearby AP... So if you have a NG router camping at CH8 the Arlo/Arlo pro base station will follow adding to interference with nearby APs in 6 and 11.

As for 5Ghz I had the same concern as it’s pretty much like a Tri Band router, so non-DFS is pretty much swamped, however in real world use it wasn’t to bad as I have R7800 literally right under it. I assume with a neighbors being further away the issue should be much less unlike 2.4Ghz. As for the power level that is an interesting find.
 
Last edited:
127 dBm is just a indicator that maximum transmit power is available within that regulatory domain. It is neither the actual transmit power, nor is even the unit of power set without the context of the country code/regulatory domain and, regardless, the maximum power would be constrained to that for the regulatory domain.

From the local max transmit power constraint, it appears, assuming an antenna directional gain of 5-8 dBi, to be moderate power on 5 GHz. It also skips explicit wide channels and has quite non-aggressive DTIM.

The real reason this is messy is the hidden backhaul and wide channel on 9 instead of 1/6/11.
 
127 dBm is just a indicator that maximum transmit power is available within that regulatory domain.

Check your math - I doubt that 5,011,872,336.3 watts is within the transmit power in the regulatory domain...

It's a bug...
 
The real reason this is messy is the hidden backhaul and wide channel on 9 instead of 1/6/11.

That's true - they really don't need to hide the backhaul network -

My major gripe is Netgear doing a Wide and Non-Standard VHT channel in 2.4GHz is unforgivable, IMHO - auto-tuning to a non-1/6/11 channel as the primary - well, that's just bad form...

The Orbi settled on CH9 as the primary, so this impacts every other WLAN in range of the Orbi network - CH1 is kind of safe, but every network that autotunes jumps there - in any event, in some testing today, I purposely put an AP on the Orbi's second channel, with clients that support 40MHz intolerant, e.g. forcing the neighbor to 20MHz, and the Orbi basically didn't care...

wifiexplorer_20180716_191551.png


I've been a bit pedantic about this in the past with VHT in the 2.4GHz band in any event, as there is no benefit to 2.4GHz other than running up marketing numbers - causes more problems that it tries to solve.

Unlikely, unless that is what Netgear state, as other (enterprise) vendors use it as an indicator.

Going back to the whole 127dBm thing - clients can take this into account when making decisions - along with current RSSI and candidate AP's - so putting a realistic value that allows the client to make the right decision if the client supports roaming...

Not only that - but the 127dBm thing just smacks of inattention to detail - which begs the ask - what else have they missed?
 
As others have noted, all tri-band/three radio routers eat up both hi and low 5 GHz channels.

Orbi isn't the only one to use 40 MHz channels other than 1,6,11 in 2.4 GHz. Linksys Velop does too.

I asked mesh vendors long ago about using 40 MHz in 2.4 GHz and was told they fall back to 20 MHz on a frame-by-frame basis if there is a channel conflict. I have never tested this. Packet captures should be able to confirm/refute this.

Once you start digging around in packet captures you'll see all sorts of odd stuff. 802.11 has a long history and old stuff never seems to go away... Get out your peak power meter to see what Tx power really is. I seriously doubt it exceeds standards.
 
From the FCC tests they show it all below the limits, I just wonder if they went far too low when it comes to staying within the limits, which may harm the performance at the edges of the coverage, especially when it comes to smartphones which like to use negative gain antennas.
 
I asked mesh vendors long ago about using 40 MHz in 2.4 GHz and was told they fall back to 20 MHz on a frame-by-frame basis if there is a channel conflict. I have never tested this. Packet captures should be able to confirm/refute this.

By setting the primary as CH9, the secondary will sit on CH5 - so there's "no conflict" when doing the clear channel check...

Once you start digging around in packet captures you'll see all sorts of odd stuff. 802.11 has a long history and old stuff never seems to go away... Get out your peak power meter to see what Tx power really is. I seriously doubt it exceeds standards.

I don't have direct access to the adjacent Orbi system, but based on RSSI detected, I suspect it right at the regulatory limit (30 dBm)
 
Is it possible for an AP to check for interference across the entire frequency range that it is actively using? For example, even though it may be using channel 9 in that case, since it is using a 40MHz width, then couldn't it detect noise in that entire 40MHz span in order to compensate for the interference?

It seems to me like that would be a smarter thing to do in order to minimize how many times a frame needs to be re-transmitted due to interference.
 
Is it possible for an AP to check for interference across the entire frequency range that it is actively using?
Sure. But any time dedicated to scanning is taken away from servicing clients, reducing available throughput.
 
Is it possible for an AP to check for interference across the entire frequency range that it is actively using? For example, even though it may be using channel 9 in that case, since it is using a 40MHz width, then couldn't it detect noise in that entire 40MHz span in order to compensate for the interference?

The Orbi does scan - it doesn't act upon the results... or it does, and decides that CH9 is still good from it's perspective...

Code:
        Overlapping BSS scan params:
                 * passive dwell: 20 TUs
                 * active dwell: 10 TUs
                 * channel width trigger scan interval: 300 s
                 * scan passive total per channel: 200 TUs
                 * scan active total per channel: 20 TUs
                 * BSS width channel transition delay factor: 5
                 * OBSS Scan Activity Threshold: 0.25 %
        Extended capabilities:
                 * HT Information Exchange Supported
                 * Extended Channel Switching
                 * TFS
                 * WNM-Sleep Mode
                 * TIM Broadcast
                 * BSS Transition
                 * SSID List
                 * Operating Mode Notification
                 * Max Number Of MSDUs In A-MSDU is unlimited
 
In that case, it can't be too overzealous in crippling its own performance. For example, some routers will drop to 20MHz channel width on the 2.4GHz band at the first sign of other APs, thus if using something like the Netgear R7800 in an urban area, then you will be stuck with slow speeds 100% of the time (unless you disable the 20/40MHz coexistence, then you get a decent throughput boost), but some others, like some of the TP-link routers I have tried, will be able to maintain 40MHz some of the time and actually get improved performance, and others like the junk that verizon provided with their service, will do 40MHz 100% of the time but perform horribly slow anyway (slower than 20MHz).

And some old ones such as the WNR3500l in a congested environment, will just completely freak out at the thought of seeing other networks, and behave somewhat normally on a less congested channel, but crap out on a moderately congested channel 6 when there are only around 50-60 other APs on that.

Overall, it is better to not have your AP be so quick to cripple its own performance. If a wider channel width and not waiting on other APs as much can offer improved performance, then shouldn't the AP take advantage and do it?
 

Attachments

  • 3500l1.jpg
    3500l1.jpg
    124.1 KB · Views: 468
  • 3500l-2.jpg
    3500l-2.jpg
    104.1 KB · Views: 759
The overlap period itself can be annoying, better to be aggressive at dropping to 20Mhz and be a good neighbor. NG products are the only one in my congested neighborhood of 20-30 nearby APs that uses non 1/6/11 channels, 40 MHz on top of that would be a bigger annoyance.

Apple still doesn’t like 40Mhz and Intel took so long to allow it and they still thankfully don’t allow forcing 40Mhz driver side either. For higher speeds 5Ghz is there so it shouldn’t be much of an issue.
 
Last edited:
Interesting - seems like it did settle on 20MHz eventually - probably got beat up by the neighbors...

Camping on CH4 (20MHz) now... you see the primary, but the other is hanging out on CH4 as well, plus the hidden SSID - would be nice for it to settle on CH6 perhaps. It's still advertising VHT there, and this, like I've mentioned before, can cause issues with older legacy 802.11 b/g/n clients.

5GHz, it's still running UNII-1 for the primary SSID, and UNII-3 for the backhaul hidden network, and levels there are still high enough to be noticed.

wifiexplorer_20180721_183609.png
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top