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

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

digital10

Regular Contributor
Any one faced significantly slow speeds on latest Voxel firmware? My internet has been super slow like 10-20Mbps all morning with internet disconnections.

I installed latest stock firmware and reset now its fast again. I can't tell if its coincidence with my ISP having down time or not.
 

theoak

Regular Contributor
Any one faced significantly slow speeds on latest Voxel firmware? My internet has been super slow like 10-20Mbps all morning with internet disconnections.

I installed latest stock firmware and reset now its fast again. I can't tell if its coincidence with my ISP having down time or not.

Okay ... it wasn't just me.

The other morning I was fighting disconnections all morning. Likewise, when it was connected, painfully slow. Restarted ISP modem and UTM ... still no joy.

I was debating on going back to .8 but I finally broke down and installed Netgear 2.7.2.104 ... stable and solid since (granted its only been a few days). I'll stick on 104 for a bit.
 
Last edited:

digital10

Regular Contributor
Okay ... it wasn't just me.

The other morning I was fighting disconnections all morning. Likewise, when it was connected, painfully slow. Restarted ISP modem and UTM ... still no joy.

I was debating on going back to .8 but I finally broke down and installed Netgear 2.7.2.104 ... stable and solid since (granted its only been a few days). I'll stick on 104 for a bit.
yes i am completely surprised, Voxel was super stable for me i just update for the heck of it. Since last update everything worked fine until today morning.

To be fair i did connect directly to ISP router which was slow to and maybe disconnects. After few hours of waiting when I installed stock firmware somehow both started working as good as always. Thats one weird coincidence.
 

Skippy Bosco

Regular Contributor
I'm running V9.2.5.2.9SF-HW and speeds have been fairly consistent with what I'm used to. I've not seen any slowness or disconnects.

I have a wired backhaul with all default settings.

Untitled.png
 

Voxel

Very Senior Member
I do not face any slowdown (I am using V9.2.5.2.9SF-HW of course) otherwise I would not release this version. I easily have my 250-275Mbps.

@Skippy Bosco is right (screenshot): speed test should be run from WebGUI of ORBI.

For example I have strange issue with my laptop Ethernet card: after resume from hibernation mode it could randomly switch to 10Mbps or 100Mbps. But sometimes 1Gbps. If I unplug the cable and plug it back - it always help: 1Gbps. If I disable the Ethernet card in Control Panel and enable it back: I have my 1Gbps.

So if I would run OOKLA directly from laptop (client connected by cable to ORBI satellite) I could get for example only 10Mbps... But I know this issue and I know that reason is not ORBI/firmware/cable but driver of Ethernet card.

So in the future please run your tests from WebGUI of ORBI.

Voxel.
 

FromThe808

New Around Here
Ok my upload speed has normalized but now another odd problem has arisen, all of a sudden my WIRED pc is showing up as a WIRELESS one in the attached devices. It's not affecting performance at all but it was showing as wired with the plug symbol but then switched to wireless a couple days ago. Anyone else experience this before and how did yall fix it?
 

digital10

Regular Contributor
One my side it could be total coincidence that once I installed the stock firmware my ISP servers went back on... but what are the odds of that...

As I said before I tested on my ISP router and it was slow too
 

Skippy Bosco

Regular Contributor
Last edited:

Voxel

Very Senior Member
This appears to be patched in 2.6.1.40, but current Voxel is based on .2.5.2

Funnily. Really.

Latest GPL source codes from NG/DNI is 2.5.2.4, what I am able to use. But note:

NG/DNI are extremely laconic in their changes log and in description of found security vulnerability. But I suppose (my guessing) they had in the mind CVE in lighttpd prior to version 1.4.54.

https://www.cvedetails.com/vulnerability-list/vendor_id-2713/Lighttpd.html

I.e. CVE-2019-11072 with high score 7.5.

Stock version 2.5.2.4 uses lighttpd version 1.4.53 (i.e. with security vulnerability) and 2.6.1.40 updated to 1.4.55 (fixed security vulnerability).

In my version lighttpd was upgraded to 1.4.54 yet in 9.2.5.1.10SF-HW (i.e. December 2019, more than year ago). In my current released version 9.2.5.2.9SF-HW (i.e. this thread): lighttpd version is 1.4.58.

And do not worry, there are a lot of more serious CVEs in the latest stock versions. So welcome back to the stock. Examples: CVE-2018-0739 (OpenSSL 1.0.2n, score 6.5), CVE-2018-9336/CVE-2018-7544 (OpenVPN 2.4.5, score 7.8 and 9.1(!)), CVE-2020-12762 (libjson-c 0.12, score: 7.8), CVE-2020-8177/ CVE-2020-8169 (curl 7.70.0, score 7.1 and 7.5) etc.

Look at scores above: 6.5, 7.8, 9.1, 7.8, 7.1, 7.5… And feel how much you are in safety using latest stock with “security fixes”.

All these CVEs are in the latest stock with “security fixes”. I do not talk re: kernel level CVE-2019-11477, CVE-2019-11478, CVE-2019-11479 fixed yet in my very first release. Really I do not have a time to enumerate all these vulnerabilities in the current stock versions (not only 2.6.xx but 2.7.xx too)…

At least all CVEs above are fixed in my build.

P.S.
Gold rule: do not allow WebGUI control from Internet. Most of NG/DNI “fixes” of security vulnerabilities are related to their WebGUI leaving all the rest CVEs intact. I hope most of you do not have hackers at your home…


Voxel.
 

Voxel

Very Senior Member
That feeling when Voxel comments about an CVE with lots of details, and then deletes his comment. :oops:o_O:eek:

Yeah... There were a lot of words. Talk less, work more. Just it is better to release the fix version.

P.S.
Just additional investigation shows that when talking PSV-2020-0301:

https://kb.netgear.com/000062507/Se...Extenders-and-Orbi-WiFi-Systems-PSV-2020-0301

NG/DNI had in their mind CVE-2020-27861:

https://nvd.nist.gov/vuln/detail/CVE-2020-27861

My initial intention to fix UA_Parser by using version from GPL sources V2.6.1.52 (Chinese specific) was wrong because of the changes in compilation flags for this version. I.e. binary incompatibility. I'll use UA_Parser from 2.7.0.70 (there are GPL sources of this version). So there was misleading info and I decided to delete it.

Anyway source codes of UA_Parser utility from 2.7.x.x and 2.6.x.x are the same:

Makefile from 2.6.1.52 (Chinese):
Code:
. . .
PKG_NAME:=attached-devices
. . .
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)

CONFIG_NETSCAN_GIT_TREEISH="da08f5b466ca86c18392d8fd406146b8329ffe8d"
CONFIG_NETSCAN_GIT_REPOSITORY="attached-devices.git"
. . .

Makefile from 2.7.0.70 (US Region):
Code:
. . .
PKG_NAME:=attached-devices
. . .
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)

CONFIG_NETSCAN_GIT_TREEISH="da08f5b466ca86c18392d8fd406146b8329ffe8d"
CONFIG_NETSCAN_GIT_REPOSITORY="attached-devices.git"
. . .

I.e. GIT commit is the same: "da08f5b466ca86c18392d8fd406146b8329ffe8d".

Bad version from 2.5.2.4 is different:

GIT commit: "a0ede1acf216a5bbd548f8716da81c3596779501".

Voxel.
 

mith_y2k

Regular Contributor
Well, It is difficult to describe concretely all the changes 2.0.44 <-> 2.0.45 and to take into consideration concretely your changes. In brief if you change

[blacklist] -> [blocked_names]
[ip_blacklist] -> [blocked_ips]
[whitelist] -> [allowed_names]


if you are using them, this should work in most of cases.

P.S.
What I would do being in your shoes: I would make the diff file of original /rom/etc/dnscrypt-proxy-2.toml from previous version of firmware (9.2.5.2.8SF-HW) with your custom version and after this I would try to apply your changes to new dnscrypt-proxy-2.toml.

All the differences of original configs 2.0.44 <-> 2.0.45


Voxel.

I wanted to loop back for people like me that might have customized the dnscrypt configuration. I realized that you can at any time check the default configuration from Voxel in /rom. Easiest thing is something like:
Code:
diff /rom/etc/dnscrypt-proxy-2.toml /etc/dnscrypt-proxy-2.toml

I have been delaying the upgrade because of this, but my plan is to basically store my changes, move my custom toml file, upgrade and keep the stock configuration from Voxel and then apply my changes as appropriate. I thought this might be helpful to others.
 

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