What's new

OpenWRT firmware build for Orbi RBR50/RBS50

  • 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!

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)
 
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:
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.
 
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...
 
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.
 
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?
 
Since this thread got me started I feel like sharing my (for me working) guest, lan, wireless, lan settings. Some noteworthy things that I've learned that hopefully help others too:
The numbering on the ports was not intuitive, the WAN is Port 1, then LAN1 is Port 2, LAN 2 = Port 3, etc.
There is a default internal VLAN setting, apparently special for the ipq40xx chipset, the tagged/untagged for vid1 changes automatically depending on additional vid settings.
Code:
swconfig dev switch0 show

VLAN 1:
    vid: 1
    ports: 0t 2t 3t 4
VLAN 2:
    vid: 2
    ports: 0t 1
so I stayed clear of the vid1 and 2, and I'm not using the WAN port of the satellite and I also removed the WAN interface of the sat. I ended up using 101 and 102, but cannot remember where I've read this, so I cannot give proper credit. I edited directly the uci files (mostly because I had to reset a couple of times without access to LuCI, but it should be possible to do everything through the gui. On the OrbiSat I disabled dnsmask, firewall through the Startup Menu. I added some comments below for clarity, better remove them.
This setup works for me, but as always no guarantee. There are 2 wireless networks on each router, always attached to the appropriate network interface, guest or lan. I provide DNS through two pi-hole servers, those settings can be ignored.
/etc/config/network on the main router:

Code:
config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'xxxxxxxxxxxb::/48'

config device
    option name 'br-lan'
    option type 'bridge'    
    list ports 'eth0.101'
    list ports 'eth1'             #seems to be necessary on the orbiSAT
    option bridge_empty '1'

config device
    option name 'br-guest'
    option type 'bridge'
    list ports 'eth0.102'
    option bridge_empty '1'

config interface 'lan'
    option device 'br-lan'
    option proto 'dhcp'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '101'
    option vid '101'
    option ports '0t 2 3 4t'  #LAN3/Port 4 is connected to Orbi

config switch_vlan
    option device 'switch0'
    option vlan '102'
    option ports '0t 4t'
    option vid '102'

config interface 'GUEST'
    option type 'bridge'
    option proto 'dhcp'
    option device 'br-guest'

config device
    option name 'eth0.101'
    option type '8021q'
    option ifname 'eth0'
    option vid '101'

config device
    option name 'eth0.102'
    option type '8021q'
    option ifname 'eth0'
    option vid '102'

/etc/config/network on the satellite router:

Code:
config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'xxxxxxx::/48'

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'eth0.101'
    option bridge_empty '1'

config device
    option name 'br-guest'
    option type 'bridge'
    list ports 'eth0.102'
    option bridge_empty '1'
    option ipv6 '0'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ipaddr '10.0.2.1'
    list dns '10.0.2.15'     #pi-holes provides dns
    list dns '10.0.2.5'      #

config interface 'wan'
    option device 'eth1'
    option proto 'static'
    list ipaddr '192.168.0.2/24'
    option gateway '192.168.0.1'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config device
    option name 'eth0'

config device
    option name 'eth1'

config switch_vlan
    option device 'switch0'
    option vlan '101'
    option vid '101'
    option ports '0t 2 3 4t'  #LAN 3/Port 4 tagged and connected to OrbiSat on LAN 3/Port4 

config switch_vlan
    option device 'switch0'
    option vlan '102'
    option ports '0t  4t'
    option vid '102'

config interface 'GUEST'
    option type 'bridge'
    option proto 'static'
    option ipaddr '192.168.100.1'
    option netmask '255.255.255.0'
    list dns '10.0.2.15'
    list dns '10.0.2.5'
    option device 'br-guest'
    option delegate '0'

config device
    option name 'eth0.101'
    option type '8021q'
    option ifname 'eth0'
    option vid '101'

config device
    option name 'eth0.102'
    option type '8021q'
    option ifname 'eth0'
    option vid '102'

some additional lines from /etc/config/dhcp main router, disabled on the satellite
Code:
config host
    option name 'OrbiSat'
    option mac '8C:3B:AD:09:C7:5D'
    option ip '10.0.2.2'

and additional lines from /etc/config/firewall main router, disabled on the satellite
Code:
config zone
    option name 'guest_zone'
    option output 'ACCEPT'
    option forward 'REJECT'
    list network 'GUEST'
    option input 'ACCEPT'

config forwarding
    option src 'guest_zone'
    option dest 'wan'

config rule
    option name 'Guest DNS'
    option src 'guest_zone'
    list dest_ip '10.0.2.15'
    list dest_ip '10.0.2.5'
    option target 'ACCEPT'
    option dest_port '53'
    option src_port '53'

config rule
    option name 'Guest DHCP'
    option src 'guest_zone'
    option src_port '67 68'
    option dest_port '67 68'
    option target 'ACCEPT'
    list dest_ip '10.0.2.1'
 
Last edited:
Ended up to move over to OpenWRT with my mesh of 4 RBR50 devices.

My problem has been long distance in between two separate houses for wireless backhaul.

Took 4-5 hours of configuring and fine tuning but I'm quite happy with the end result.

As mentioned earlier OpenWRT requires a lot more configuration, especially for mesh environment with multiple VLAN's but offers predictability and reliability I was lacking with Netgear and even with Voxel.

With OpenWRT it is possible to build up a true 802.11s mesh using the radio of your choice and not to rely on Netgear's algorithm arbitrarily making the decision.
 
Ended up to move over to OpenWRT with my mesh of 4 RBR50 devices.

My problem has been long distance in between two separate houses for wireless backhaul.

Took 4-5 hours of configuring and fine tuning but I'm quite happy with the end result.

As mentioned earlier OpenWRT requires a lot more configuration, especially for mesh environment with multiple VLAN's but offers predictability and reliability I was lacking with Netgear and even with Voxel.

With OpenWRT it is possible to build up a true 802.11s mesh using the radio of your choice and not to rely on Netgear's algorithm arbitrarily making the decision.
Could you share a guide on how you set this up? I’d more than happy to donate to someone who could share the setup process. Thanks!
 
Could you share a guide on how you set this up? I’d more than happy to donate to someone who could share the setup process. Thanks!

Guide is somewhat an overstatement but I can provide you brief instructions on how to get started.

Check out the device page from OpenWRT hwdata. E.g. RBR50

From there you can open git commit and check installation instructions.

You can use either GUI of NMRPFlash for installation of devices one by one and the latter can be used if something goes wrong and you need to recover.

Once installed you will need to use LAN connectivity to reach the devices and configure admin password, basic networking and LuCI, if you want to use GUI for configuration. There are good instructions on OpenWRT Wiki Quick start guide

Following the quick start guide you can then configure WAN, LAN and WLAN for "router" devices and LAN and WLAN for "satellite" devices.

If you want to use wireless mesh to provide backhaul connectivity you can use 802.11s guide to establish mesh network on all devices.

To configure additional virtual networks there are e.g. Guest WiFi instructions in Wiki.
 
Guide is somewhat an overstatement but I can provide you brief instructions on how to get started.

Check out the device page from OpenWRT hwdata. E.g. RBR50

From there you can open git commit and check installation instructions.

You can use either GUI of NMRPFlash for installation of devices one by one and the latter can be used if something goes wrong and you need to recover.

Once installed you will need to use LAN connectivity to reach the devices and configure admin password, basic networking and LuCI, if you want to use GUI for configuration. There are good instructions on OpenWRT Wiki Quick start guide

Following the quick start guide you can then configure WAN, LAN and WLAN for "router" devices and LAN and WLAN for "satellite" devices.

If you want to use wireless mesh to provide backhaul connectivity you can use 802.11s guide to establish mesh network on all devices.

To configure additional virtual networks there are e.g. Guest WiFi instructions in Wiki.
Thanks so much!!!
 
I was able to get this up and running. Thanks for your help! I did have one question, did anyone figure out how to turn off the green led light at the top of the Orbi off? It’s a bit annoying lol it pulses white, then just stays solid green after turning it on.
 
What are the network speeds you are getting? I’m getting only 200-250 Mbps when wired but was getting 1,000 mbps when wired with voxel. I am connected to the router in both scenarios.
 
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)
I don't see any RBx50 (ipq40xx) NSS builds though, I see builds for ipq806x devices like the R7800 but I'm coming up empty for the 40xx hardware. I've got gigabit so it's kind of important.
 
I don't see any RBx50 (ipq40xx) NSS builds though, I see builds for ipq806x devices like the R7800 but I'm coming up empty for the 40xx hardware. I've got gigabit so it's kind of important.

Dakota has great support in OpenWRT

 

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