What's new

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

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

Voxel

Part of the Furniture
ProFTPD
Got no error message, but also could not connect to a server. No response. Just timed out after 20 seconds.

There is no ProFTPD init script and/or its setting or control over the WebGUI (not like in R7800/R9000). So it is necessary to run it manually from SSH/telnet. Or to create own scheme with

QuickStart.txt

. . .
2. Overlay partition on USB.
. . .

Voxel.
 

Beach

New Around Here
I recently updated to V9.2.5.2.27.1SF-HW and ever since about a week ago I have noticed that the network has been extremely unreliable.

Long story short and after many pulled out hairs, I think I have the issue and the solution. It appears there is a known bug from at least 2 years ago where if you have automatic Daylight Savings Time adjust on, as well as the traffic meter on, as well as DST actually being active (like it recently changed), it causes the DNS to fail and even though the router reports internet is good, and the onboard speed test is good. Regardless of this, all connected devices are unable to use the internet due to DNS failures. A simple reboot fixes it, but I found this reddit post that had a few more solutions including just disabling either traffic meter or the automatic DST adjust. Then I was thinking, this post is from a while ago, maybe there has been an official fix, so to the netgear firmware release notes I go, and it appears that it was fixed in release 2.7.3.22 (Fixes the DNS query failure issue that occurs when traffic meter and daylight saving are enabled.)

So here comes my question, is this on the radar for the voxel firmware and intentionally disregarded or can voxel be rebased with these changes (or newer) as well?

At the end of the day, it does not really matter as I just disabled traffic meter (which I never really had a use for anyway, just thought it was cool for analytics) but it would be nice to see this bug fixed regardless as it might help someone out in the future.

In any case, I really appreciate all of the hard work you put into these firmwares as they are for the most part rock solid and still my go to recommendation for anyone that has Orbi routers.
 
Last edited:

Voxel

Part of the Furniture
I recently updated to V9.2.5.2.27.1SF-HW and ever since about a week ago I have noticed that the network has been extremely unreliable.

Long story short and after many pulled out hairs, I think I have the issue and the solution. It appears there is a known bug from at least 2 years ago where if you have automatic Daylight Savings Time adjust on, as well as the traffic meter on, as well as DST actually being active (like it recently changed), it causes the DNS to fail and even though the router reports internet is good, and the onboard speed test is good. Regardless of this, all connected devices are unable to use the internet due to DNS failures. A simple reboot fixes it, but I found this reddit post that had a few more solutions including just disabling either traffic meter or the automatic DST adjust. Then I was thinking, this post is from a while ago, maybe there has been an official fix, so to the netgear firmware release notes I go, and it appears that it was fixed in release 2.7.3.22 (Fixes the DNS query failure issue that occurs when traffic meter and daylight saving are enabled.)

So here comes my question, is this on the radar for the voxel firmware and intentionally disregarded or can voxel be rebased with these changes (or newer) as well?

At the end of the day, it does not really matter as I just disabled traffic meter (which I never really had a use for anyway, just thought it was cool for analytics) but it would be nice to see this bug fixed regardless as it might help someone out in the future.

In any case, I really appreciate all of the hard work you put into these firmwares as they are for the most part rock solid and still my go to recommendation for anyone that has Orbi routers.
Thanks for your post and researching the Netgear stock firmware logs. You know, it's quite problematic for me to check all possible problems related to location and specifics of this location. Your country has DST and mine (ugh, unfortunately) does not. I use the RBK50 all the time and checking such problems would not be appreciated by my family members.

Next. To you for your information. Using Traffic Metter is very unhealthy for your RBR/RBS. Traffic Metter kills the nand memory of Netgear routers by constantly writing to that memory. It is strongly discouraged to enable Traffic Metter.

Next. I try to unify all packages used in my R7800/R8900/R9000/ORBI-RBK50/ORBI-LBR20 firmware. One version of the package for all devices. My RBK50 version used for a long time the dnsmasq (DNS query processing) version from the R9000 firmware. So all changes V2.7.0.70->V2.7.3.22 were present in my version for RBK50 for several years already. After your signal I checked what changed in the latest versions for R7800/R8900/R9000 in dnsmasq (DNS query processing) and found that for these routers these changes were obviously removed. That is, if we call the changes V2.7.0.70->V2.7.3.22 as "patch", then:

The latest R7800 stock firmware removes this "patch".​
The last stock firmware R8900 removes this "patch".​
The last stock firmware R9000 removes this "patch".​
The latest RBK50 stock firmware adds this "patch" from V2.7.3.22 onwards.​
My RBK50 firmware versions have been using this "patch" for a very long time.​

Thus, what can I do for the RBK50:

(1) Remove this "patch" for RBK50 unifying with R7800/R8900/R9000/LBR20.
(2) Use the trafficmeter package from the latest stock version of the RBK50 firmware.

(I cannot trace out Traffic Meter because it is in binary form on NG GPL)

That's what I plan to do. OK?

Voxel.
 

Beach

New Around Here
Thanks for your post and researching the Netgear stock firmware logs. You know, it's quite problematic for me to check all possible problems related to location and specifics of this location. Your country has DST and mine (ugh, unfortunately) does not. I use the RBK50 all the time and checking such problems would not be appreciated by my family members.

Next. To you for your information. Using Traffic Metter is very unhealthy for your RBR/RBS. Traffic Metter kills the nand memory of Netgear routers by constantly writing to that memory. It is strongly discouraged to enable Traffic Metter.

Next. I try to unify all packages used in my R7800/R8900/R9000/ORBI-RBK50/ORBI-LBR20 firmware. One version of the package for all devices. My RBK50 version used for a long time the dnsmasq (DNS query processing) version from the R9000 firmware. So all changes V2.7.0.70->V2.7.3.22 were present in my version for RBK50 for several years already. After your signal I checked what changed in the latest versions for R7800/R8900/R9000 in dnsmasq (DNS query processing) and found that for these routers these changes were obviously removed. That is, if we call the changes V2.7.0.70->V2.7.3.22 as "patch", then:

The latest R7800 stock firmware removes this "patch".​
The last stock firmware R8900 removes this "patch".​
The last stock firmware R9000 removes this "patch".​
The latest RBK50 stock firmware adds this "patch" from V2.7.3.22 onwards.​
My RBK50 firmware versions have been using this "patch" for a very long time.​

Thus, what can I do for the RBK50:

(1) Remove this "patch" for RBK50 unifying with R7800/R8900/R9000/LBR20.
(2) Use the trafficmeter package from the latest stock version of the RBK50 firmware.

(I cannot trace out Traffic Meter because it is in binary form on NG GPL)

That's what I plan to do. OK?

Voxel.
Honestly, I am not sure what would be the best path going forward from a code maintenance perspective (I would lean towards whatever is easiest for all firmwares) and if you strongly discourage using traffic meter that is good enough for me. Maybe it would be easiest to just disable this feature altogether with a note in the readme about the performance hit you can take along with the stability issues with this newly found bug and recommending them to either revert to official firmware if they really need it, or write a forum post to discuss further.
 
Last edited:

quackamole

New Around Here
I recently updated to V9.2.5.2.27.1SF-HW and ever since about a week ago I have noticed that the network has been extremely unreliable.

Long story short and after many pulled out hairs, I think I have the issue and the solution. It appears there is a known bug from at least 2 years ago where if you have automatic Daylight Savings Time adjust on, as well as the traffic meter on, as well as DST actually being active (like it recently changed), it causes the DNS to fail and even though the router reports internet is good, and the onboard speed test is good. Regardless of this, all connected devices are unable to use the internet due to DNS failures. A simple reboot fixes it, but I found this reddit post that had a few more solutions including just disabling either traffic meter or the automatic DST adjust. Then I was thinking, this post is from a while ago, maybe there has been an official fix, so to the netgear firmware release notes I go, and it appears that it was fixed in release 2.7.3.22 (Fixes the DNS query failure issue that occurs when traffic meter and daylight saving are enabled.)

So here comes my question, is this on the radar for the voxel firmware and intentionally disregarded or can voxel be rebased with these changes (or newer) as well?

At the end of the day, it does not really matter as I just disabled traffic meter (which I never really had a use for anyway, just thought it was cool for analytics) but it would be nice to see this bug fixed regardless as it might help someone out in the future.

In any case, I really appreciate all of the hard work you put into these firmwares as they are for the most part rock solid and still my go to recommendation for anyone that has Orbi routers.
I was also have major stability issues, and found that traffic monitoring was on AND DST was also auto set... turned traffic off and voila, stability has returned!

Turning traffic monitoring off also sped up my web interface tremendously. No clue when I stupidly turned it on...
 

agneev

Occasional Visitor
Hello,

I'm running this version of firmware on my orbi and came across this article today:


The most severe of the vulnerabilities, tracked as CVE-2022-37337, resides in the access control functionality of the RBR750. Hackers can exploit it to remotely execute commands by sending specially crafted HTTP requests to the device.
The severity of the flaw is rated 9.1 out of a possible 10.

Though the article mentions the RBR750, I'm curious whether it affects RBK models.
 

Voxel

Part of the Furniture
Hello,

I'm running this version of firmware on my orbi and came across this article today:





Though the article mentions the RBR750, I'm curious whether it affects RBK models.

There is no point in worrying (yet). The CVE only indicates a problem with the RBR750 only. And the problem is related to http request, which means accessing the device via http (not https) from your home LAN. So if you have hackers at you home (maybe funny, right?), well then there is cause for concern. From the outside, it's impossible.

Voxel.
 

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