Voxel Custom firmware build for Orbi RBK50/RBK53 (RBR50, RBS50) v. 9.2.5.1.33SF-HW & v. 9.2.5.1.34SF-HW

[Voxel]

Continuation of

https://www.snbforums.com/threads/custom-firmware-build-for-orbi-rbk50-v-2-5-0-42sf-hw.60308/
. . .
https://www.snbforums.com/threads/c...-v-9-2-5-1-18sf-hw-v-9-2-5-1-18-1sf-hw.64414/
https://www.snbforums.com/threads/c...50-rbk53-rbr50-rbs50-v-9-2-5-1-19sf-hw.64782/

New version of my custom firmware build: 9.2.5.1.33SF-HW.

Changes (vs 9.2.5.1.19SF-HW):

1. Integration of changes from the stock v. 2.5.1.32.
2. dropbear package is upgraded 2020.79->2020.80.
3. wireguard package is upgraded 1.0.20200601->1.0.20200623.
4. curl package is upgraded 7.70.0->7.71.1.
5. stubby package is upgraded 0.2.6->0.3.0.
6. yaml package (used in stubby) is upgraded 0.2.4->0.2.5.
7. haveged package is upgraded 1.9.8->1.9.12.
8. elfutils package is upgraded 0.161->0.179.
9. libjson-c package is upgraded 0.13.1->0.14 (including fix of CVE-2020-12762).
10. etherwake 1.09 package is added.

[Edited]

Version 9.2.5.1.34SF-HW.

Changes (vs 9.2.5.1.33SF-HW):

1. Toolchain: GCC is upgraded 9.3.0->10.2.0.
2. Toolchain: Go is upgraded 1.14.3->1.14.6.
3. inetd daemon binary: downgrade to version from the stock 2.5.1.16.
4. libjson-c 0.12.1 package: fix of CVE-2020-12762.
5. wireguard package is upgraded 1.0.20200623->1.0.20200712.
6. proftpd package is upgraded 1.3.6d->1.3.6e.
7. iperf3 package is upgraded 3.7->3.8.1.
8. haveged package is upgraded 1.9.12->1.9.13.
9. sysstat package is upgraded 12.2.1-12.2.2.
10. bridge-utils package is upgraded 1.6->1.7.

The link is:

https://www.voxel-firmware.com (thanks to vladlenas for his help with hosting).

Voxel.

 

[soundersdude]

Apologize if this was answered somewhere else, for upgrading (or coming over from Stock), is it best practice to start with the Satellites (RBS50) first then the main Router (RBR50) or Main first then Satellite?

Thank you, and thank you so much for doing this as a hobby.
Immensely appreciated!

 

[kalpik]

Apologize if this was answered somewhere else, for upgrading (or coming over from Stock), is it best practice to start with the Satellites (RBS50) first then the main Router (RBR50) or Main first then Satellite?

Thank you, and thank you so much for doing this as a hobby.
Immensely appreciated!

Satellite first, then router.

 

[cdzo72]

Has the reset bug been fixed?

Sent from my SM-N9600 using Tapatalk

 

[Skippy Bosco]

Has the reset bug been fixed?

Sent from my SM-N9600 using Tapatalk

It is not listed in the changelog, so no. To do a factory reset, flash stock ROM back on, factory reset and then flash VOXEL back on.

Never factory reset with VOXEL or you will soft brick and need to flash stock ROM back on via TFTP.

 

[digital10]

I just wanted to report that everything is superb and no issues. Thanks Voxel!

We live in funny times where someone is impressed that the product he bought actually works as advertised. On the other side of things, modern tech is mind boggling that we take for granted. I still remember Steve Jobs saying that video calls on the iphone feels like something from The Jetsons. Indeed it is!

 

[Deleted member 22229]

Steve Jobs saying that video calls on the iphone feels like something from The Jetsons. Indeed it is!

The Jetson's was based in the year 2062. So just wait and see what else blows the mind and rips money from the wallet.

 

[Skippy Bosco]

I upgraded from 9.2.5.1.17SF-HW to 9.2.5.1.33SF-HW. The upgrade took less than 5 minutes for both satellites and router. Can't say if it is any better, but certainly not any worse. Fast. Stable. Great job.

 

[theoak]

2.5.1.32 Netgear got pulled from their website. No reasons as to why ...

https://kb.netgear.com/000062062/RBR50-RBS50-Firmware-Version-2-5-1-32

 

[Voxel]

2.5.1.32 Netgear got pulled from their website. No reasons as to why ...

There are some apparent bugs in 2.5.1.33 (I had to fix them in my version)... Maybe because of this.

Plus: bug I could not fix because of lacking source codes: inetd daemon (started automatically after reboot) eats significant CPU time (kernel). It is not visible in the 'top' command from busybox, but visible from Entware version of top. Because of this there is slowdown of the speed (RBR<--->RBS).

Workaround is to stop this daemon manually on RBR and RBS from telnet/ssh:

/etc/init.d/inetd stop

After this CPU is almost idle and speed is increased:

I have no ideas what is inside of inetd and what is this bug (I use this binary as-is). And speed if Orbi is increased after stopping this daemon. No such problems in previous stock version.

Voxel.

 

[theoak]

I experienced this slowdown I believe. For that reason I dropped back to 9.2.5.1.19. Thanks for all that you do.

 

[Voxel]

I experienced this slowdown I believe.

Me too. But workaround (intetd stop) works for me.

Voxel.

 

[Skippy Bosco]

There are some apparent bugs in 2.5.1.33 (I had to fix them in my version)

Can you clarify this statement? When you say that you fixed it in your version, do you mean the intetd stop or some other method?

I'm not seeing slow down or a high CPU time when I view with Entware TOP. (I'm running 2.5.1.33)

Just trying to figure out if I should proactively do something like rollback.

 

[Voxel]

Can you clarify this statement? When you say that you fixed it in your version, do you mean the intetd stop or some other method?

No. I mean other bugs. Not inetd bug. For example such bugs (in the stock) as

/usr/bin/dal_ash refers (absolute path (!)) to /opt/bitdefender/libbdbroker.so when it is located in /lib (/lib/libbdbroker.so)

or

/etc/xagent/upagent/switch.sh script contains the line:

. . .
        /etc/init.d/upagent.init restart
. . .

but there is NO such file "upagent.init" in /etc/init.d directory. There is /etc/init.d/UPAgent.

etc.

So "inetd bug" is left. Workaround in my post above, to stop it. If I replace manually this binary /usr/sbin/inetd by version taken from previous stock 2.5.1.16 there are no such issue. Other workaround is to use my "Overlay on USB" method to do the same: replacement /usr/sbin/inetd from previous version. Probably I should release such version with old inetd.

I'm not seeing slow down or a high CPU time when I view with Entware TOP. (I'm running 2.5.1.33)

Please paste the screenshot.

Voxel

 

[Voxel]

Probably I should release such version with old inetd.

You may check 9.2.5.1.34SF-HW with inetd from stock 2.5.1.16.

This version is compiled by new GCC 10.2.0 plus some updated packages and CVE-2020-12762 fix for libjson-c v. 0.12.1. I use this version (testing) with my Orbi. No issues with CPU load in idle state. iperf3 results are better RBR<--->RBS vs 33SF-HW with inetd started.

It would be good if theoak could try this version (he faced slowdown too).

Voxel.

 

[Skippy Bosco]

You may check 9.2.5.1.34SF-HW with inetd from stock 2.5.1.16.

I've just loaded it on and all seems well with 9.2.5.1.34SF-HW

 

[Julian Brooks]

@Voxel Just to be clear, there is no need to ssh into the RBR50 or RBS50 and "etc/init.d/inetd stop" with firmware V9. 2.5.1.34F-HW?

 

[Voxel]

@Voxel Just to be clear, there is no need to ssh into the RBR50 or RBS50 and "etc/init.d/inetd stop" with firmware V9. 2.5.1.34F-HW?

No needs to stop anything manually (in 34SF-HW). Just boot your RBR and RBS and use with your clients.

Voxel.

 

[theoak]

You may check 9.2.5.1.34SF-HW with inetd from stock 2.5.1.16.

This version is compiled by new GCC 10.2.0 plus some updated packages and CVE-2020-12762 fix for libjson-c v. 0.12.1. I use this version (testing) with my Orbi. No issues with CPU load in idle state. iperf3 results are better RBR<--->RBS vs 33SF-HW with inetd started.

It would be good if theoak could try this version (he faced slowdown too).

Voxel.

Okay, I have always been a sucker for punishment. I will download and install today. Wish me luck

Edit:

Give me a day or two. I really noticed it when streaming. Buffering was crazy bad with .33. I rolled back to .19 and buffering was gone.

We'll see how .34 does ...

 

[Skippy Bosco]

There is a bit of discussion over the possibility that Orbi has a potential WPS vulnerability.

https://www.reddit.com/r/orbi/comments/hxufnx

The belief is that while they have hidden the PIN functionality, a pin still exists and is visible here:

Orbi Login & Setup | NETGEAR

The Orbi Web Interface and Orbi Admin App makes it easy to login and configure your Orbi WiFi System.

orbilogin.com

And is discoverable with network scanning tools:

And that pin can then be used to discover the wifi password.

While this thread disccuses RBR850 (because that is what OP has) it presumably exists on the RBR50 as well.

I'm not entirely sure if this is a real issue, or if it is what options would be available to disable it via configuration, but wanted to share the information here in case anyone had any thoughts.