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

[digital10]

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]

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.

 

[digital10]

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]

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.

 

[Voxel]

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]

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]

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]

This was just released:

https://kb.netgear.com/000062507/Security-Advisory-for-Unauthenticated-Command-Injection-Vulnerability-on-Some-Extenders-and-Orbi-WiFi-Systems-PSV-2020-0301|

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

Would this be a good opportunity to start the process of updating the base stock image to 2.6 branch?

Secondarily, the latest 2.7.x releases are no longer being flagged as American only. Does that restriction no longer apply?

 

[Voxel]

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.

 

[Skippy Bosco]

Thank You Voxel for your forethought and continued support.

 

[Skippy Bosco]

Selective integration.

That feeling when Voxel comments about an CVE with lots of details, and then deletes his comment.

 

[Voxel]

That feeling when Voxel comments about an CVE with lots of details, and then deletes his comment.

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):

. . .
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):

. . .
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]

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

http://voxel-firmware.com/Downloads/dnscrypt.patch

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:

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.