OpenWRT firmware build for Orbi RBR50/RBS50

Atko

Occasional Visitor
Recently found out that the snapshot and release candidate versions of the base OpenWrt have support for the RBR50v1/RBS50v1 (it’s the same hardware anyways, by default it will ignore anything setup previously and setup a RBS50 to an RBR50). Was wondering if anyone else has been using the firmware and has any experiences?

So far I have been running it and it seems to be stable enough, and has much better performance than either the stock Netgear firmware or Voxel’s awesome firmware. Here is my current list of pros and cons:

Pros:
  • Much faster overall network performance, due to a number of reasons mostly because I can control the meshing a lot better (I have 5 satellites).
    • The stock Orbi firmware and Voxel’s firmware prefers to use wifi backhaul when you daisy chain, at least for me. Everytime you use a wifi backhaul on the Orbi (it uses WDS) latency increases and bandwidth is reduced because of radio interference etc.
    • You can specify a different channel for each AP to reduce radio interference across the network (stock has a single channel for all satellites and routers).
    • You can specify the power for each radio on each AP to further reduce radio interference and promote a better roaming handoff.
  • Multiple SSID’s for 5Ghz and 2.4Ghz networks are possible without much issue.
  • Different security settings for 5Ghz and 2.4Ghz networks are possible.
  • 802.11r fast roaming works properly, this never worked for me on the stock firmware, it would take a long time for me to switch over to the closest satellite with significant packet loss.
  • Supports 802.11s on the backhaul radio, which translates into better multi-hop wireless backhaul performance.
    • Stock Orbi firmware, by default, sets up 3 different hidden WDS networks for the backhaul, presumably one for management, one for backhauling the guest network and one for backhauling the primary network.
  • Much faster router bootup and satellite bootup
    • The configuration is no longer controlled by the router so there is no waiting period for a config sync to happen and nor any period when the satellites need to decide which is the best route to take (backhaul connections are hard coded).
  • Much faster user interface, since it doesn’t need to contact all the satellites to enumerate devices and connections.
  • You can do advanced mesh routing with batman-adv
  • Much more information available about AP, clients, etc thru the web interface
  • Configuration changes are isolated to the device or to the interfaces that are affected, reducing outages when something has to change.
    • Stock firmware triggers a configuration resync on most operations (clicking apply after adding a static DHCP lease would basically restart the network).

Cons:
  • It’s better in the snapshot version than the current release candidate. In either case, support and stability may not be good for a network you rely on #YOLO.
  • Unsure if beamforming and MU-MIMO are not working. I haven’t read the documentation yet (does it work properly in the stock firmware? I don’t think I ever saw any wifi improvement when I checked this off).
  • 802.11k and 802.11v are supported, but it seems the configuration is manual and complicated.
  • Much harder to configure. Each AP needs to be configured individually from its own interface. While this is typically a one time task, it still requires planning and testing.
  • It’s a manual step to change each device to a satellite by deleting the WAN networks and connecting the ethernet port into the existing bridge.
  • No Netgear software (bloatware) i.e. Disney Circle, Netgear Armor, Netgear Smart Parental Controls, Netgear interfaces, Netgear configuration utilities and synchronization tools, Netgear mobile app integration (Are these a pros or cons? you decide).
  • No simple “add satellite/sync” button. Adding a satellite must be done manually on both the router and the satellite.
  • If you want a resilient network that automatically adjusts when AP’s are down, you will have to manually configure it, e.g. use batman-adv to manage the mesh networking.
  • Setting up a guest network is complicated, especially with a wired backhaul. To make my setup simple, I use the router as the single access point for my guest network. This is at the expense of visitors having sub-optimal coverage and performance. To get a guest network up and running properly, it’s likely it needs a separate wifi mesh without wired backhaul, a wifi mesh and a VLAN trunking or an overlay network like VXLAN or GRE to bring the guest traffic from each satellite back to the router. I am not sure how the stock Orbi firmware does this.

Notes:
  • You cannot have two 802.11s mesh networks on a single radio
  • Backhaul radio only supports the following channels, unfortunately I live too close to an airport to use the “radar detection” channels:
    • * 5500 MHz [100] (24.0 dBm) (radar detection)
    • * 5520 MHz [104] (24.0 dBm) (radar detection)
    • * 5540 MHz [108] (24.0 dBm) (radar detection)
    • * 5560 MHz [112] (24.0 dBm) (radar detection)
    • * 5580 MHz [116] (24.0 dBm) (radar detection)
    • * 5600 MHz [120] (24.0 dBm) (radar detection)
    • * 5620 MHz [124] (24.0 dBm) (radar detection)
    • * 5640 MHz [128] (24.0 dBm) (radar detection)
    • * 5660 MHz [132] (24.0 dBm) (radar detection)
    • * 5680 MHz [136] (24.0 dBm) (radar detection)
    • * 5700 MHz [140] (24.0 dBm) (radar detection)
    • * 5720 MHz [144] (24.0 dBm) (radar detection)
    • * 5745 MHz [149] (30.0 dBm)
    • * 5765 MHz [153] (30.0 dBm)
    • * 5785 MHz [157] (30.0 dBm)
    • * 5805 MHz [161] (30.0 dBm)
    • * 5825 MHz [165] (30.0 dBm)
    • * 5845 MHz [169] (27.0 dBm) (no IR)
  • Non-backhaul 5Ghz radio only supports the following channels, unfortunately I live too close to an airport to use the “radar detection” channels:
    • * 5180 MHz [36] (23.0 dBm)
    • * 5200 MHz [40] (23.0 dBm)
    • * 5220 MHz [44] (23.0 dBm)
    • * 5240 MHz [48] (23.0 dBm)
    • * 5260 MHz [52] (24.0 dBm) (radar detection)
    • * 5280 MHz [56] (24.0 dBm) (radar detection)
    • * 5300 MHz [60] (24.0 dBm) (radar detection)
    • * 5320 MHz [64] (24.0 dBm) (radar detection)
 

ducksoup18

New Around Here
Was the flash pretty straight forward? Did you do the satellites first and then the router? Would like to get OpenWRT on my orbi setup so i can setup LAN and WLAN VLANS. Any info would be greatly appreciated. My setup right now is ISP > RBR50 > Unmanaged Switch > 2x RBS50s. What i'd like to do is: ISP > OPNSense > unmanaged switch > 3x RBx50s as APs. I found this video:
and he mentioned that you can configure your OpenWRT with batman-adv as a huge VLAN setup if you dont have a router with 2 NICs (which my opnsense box doesnt. i could add one tho. always that option).
 
Last edited:

crowdme2

Occasional Visitor
Recently found out that the snapshot and release candidate versions of the base OpenWrt have support for the RBR50v1/RBS50v1 (it’s the same hardware anyways, by default it will ignore anything setup previously and setup a RBS50 to an RBR50). Was wondering if anyone else has been using the firmware and has any experiences?

So far I have been running it and it seems to be stable enough, and has much better performance than either the stock Netgear firmware or Voxel’s awesome firmware. Here is my current list of pros and cons:

Pros:
  • Much faster overall network performance, due to a number of reasons mostly because I can control the meshing a lot better (I have 5 satellites).
    • The stock Orbi firmware and Voxel’s firmware prefers to use wifi backhaul when you daisy chain, at least for me. Everytime you use a wifi backhaul on the Orbi (it uses WDS) latency increases and bandwidth is reduced because of radio interference etc.
    • You can specify a different channel for each AP to reduce radio interference across the network (stock has a single channel for all satellites and routers).
    • You can specify the power for each radio on each AP to further reduce radio interference and promote a better roaming handoff.
  • Multiple SSID’s for 5Ghz and 2.4Ghz networks are possible without much issue.
  • Different security settings for 5Ghz and 2.4Ghz networks are possible.
  • 802.11r fast roaming works properly, this never worked for me on the stock firmware, it would take a long time for me to switch over to the closest satellite with significant packet loss.
  • Supports 802.11s on the backhaul radio, which translates into better multi-hop wireless backhaul performance.
    • Stock Orbi firmware, by default, sets up 3 different hidden WDS networks for the backhaul, presumably one for management, one for backhauling the guest network and one for backhauling the primary network.
  • Much faster router bootup and satellite bootup
    • The configuration is no longer controlled by the router so there is no waiting period for a config sync to happen and nor any period when the satellites need to decide which is the best route to take (backhaul connections are hard coded).
  • Much faster user interface, since it doesn’t need to contact all the satellites to enumerate devices and connections.
  • You can do advanced mesh routing with batman-adv
  • Much more information available about AP, clients, etc thru the web interface
  • Configuration changes are isolated to the device or to the interfaces that are affected, reducing outages when something has to change.
    • Stock firmware triggers a configuration resync on most operations (clicking apply after adding a static DHCP lease would basically restart the network).

Cons:
  • It’s better in the snapshot version than the current release candidate. In either case, support and stability may not be good for a network you rely on #YOLO.
  • Unsure if beamforming and MU-MIMO are not working. I haven’t read the documentation yet (does it work properly in the stock firmware? I don’t think I ever saw any wifi improvement when I checked this off).
  • 802.11k and 802.11v are supported, but it seems the configuration is manual and complicated.
  • Much harder to configure. Each AP needs to be configured individually from its own interface. While this is typically a one time task, it still requires planning and testing.
  • It’s a manual step to change each device to a satellite by deleting the WAN networks and connecting the ethernet port into the existing bridge.
  • No Netgear software (bloatware) i.e. Disney Circle, Netgear Armor, Netgear Smart Parental Controls, Netgear interfaces, Netgear configuration utilities and synchronization tools, Netgear mobile app integration (Are these a pros or cons? you decide).
  • No simple “add satellite/sync” button. Adding a satellite must be done manually on both the router and the satellite.
  • If you want a resilient network that automatically adjusts when AP’s are down, you will have to manually configure it, e.g. use batman-adv to manage the mesh networking.
  • Setting up a guest network is complicated, especially with a wired backhaul. To make my setup simple, I use the router as the single access point for my guest network. This is at the expense of visitors having sub-optimal coverage and performance. To get a guest network up and running properly, it’s likely it needs a separate wifi mesh without wired backhaul, a wifi mesh and a VLAN trunking or an overlay network like VXLAN or GRE to bring the guest traffic from each satellite back to the router. I am not sure how the stock Orbi firmware does this.

Notes:
  • You cannot have two 802.11s mesh networks on a single radio
  • Backhaul radio only supports the following channels, unfortunately I live too close to an airport to use the “radar detection” channels:
    • * 5500 MHz [100] (24.0 dBm) (radar detection)
    • * 5520 MHz [104] (24.0 dBm) (radar detection)
    • * 5540 MHz [108] (24.0 dBm) (radar detection)
    • * 5560 MHz [112] (24.0 dBm) (radar detection)
    • * 5580 MHz [116] (24.0 dBm) (radar detection)
    • * 5600 MHz [120] (24.0 dBm) (radar detection)
    • * 5620 MHz [124] (24.0 dBm) (radar detection)
    • * 5640 MHz [128] (24.0 dBm) (radar detection)
    • * 5660 MHz [132] (24.0 dBm) (radar detection)
    • * 5680 MHz [136] (24.0 dBm) (radar detection)
    • * 5700 MHz [140] (24.0 dBm) (radar detection)
    • * 5720 MHz [144] (24.0 dBm) (radar detection)
    • * 5745 MHz [149] (30.0 dBm)
    • * 5765 MHz [153] (30.0 dBm)
    • * 5785 MHz [157] (30.0 dBm)
    • * 5805 MHz [161] (30.0 dBm)
    • * 5825 MHz [165] (30.0 dBm)
    • * 5845 MHz [169] (27.0 dBm) (no IR)
  • Non-backhaul 5Ghz radio only supports the following channels, unfortunately I live too close to an airport to use the “radar detection” channels:
    • * 5180 MHz [36] (23.0 dBm)
    • * 5200 MHz [40] (23.0 dBm)
    • * 5220 MHz [44] (23.0 dBm)
    • * 5240 MHz [48] (23.0 dBm)
    • * 5260 MHz [52] (24.0 dBm) (radar detection)
    • * 5280 MHz [56] (24.0 dBm) (radar detection)
    • * 5300 MHz [60] (24.0 dBm) (radar detection)
    • * 5320 MHz [64] (24.0 dBm) (radar detection)
Super helpful.
 

sfx2000

Part of the Furniture
Cool...

Only downsides are:

1) None of the closed source QSDK special sauce, so NAT accel is out... for most this might not be an issue, but LAN-WAN performance will not use the NSS cores in the IPQ80xx chipset by default - there are community builds where folks have merged closed source in, but that's a community build, not something that someone can just do a git clone from Master (or release branches)

2) ATH10K-CT drivers - there are limits in the drivers that one doesn't have in the closed source QSDK - that being said, CT drivers are pretty good, and the upstream devs for that driver have insight under NDA from Qualcomm.

3) OpenWRT and complexity as mentioned - it's not a big deal for an experienced OpenWRT user, but for many, OpenWRT can be a bit daunting, things are not "obvious" in some places...

Anyone that decides to explore - one key piece of advice, back up your ART partitions, as those contain the RF cal specific to the unit, along with other parametric info (like MAC addresses). Losing the ART is a very bad thing...
 

sfx2000

Part of the Furniture
Any link on how to do this? ive only found out how to do on openwrt, any way to backup before flashiing ?

If you're unsure how to back up MTD partitions, you're not a likely candidate to use OpenWRT on a complex device/platform like the Orbi's...

I personally don't have the time to help walk you thru things.

There are well documented steps on how to do things, search the internet - good place to start is the OpenWRT wiki itself.
 

ducksoup18

New Around Here
If i have wired backhaul setup on my orbis currently, does that mean the wireless backhaul radios could be a part of the regular AP radios?
 

Latest threads

Sign Up For SNBForums Daily Digest

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