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

[Voxel]

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]

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.

 

[Voxel]

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]

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.

 

[quackamole]

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]

Hello,

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

If your Netgear Orbi router isn’t patched, you’ll want to change that pronto

The threat is serious enough to warrant a manual check ASAP.

arstechnica.com

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]

Hello,

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

If your Netgear Orbi router isn’t patched, you’ll want to change that pronto

The threat is serious enough to warrant a manual check ASAP.

arstechnica.com

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.

 

[yiga]

Check QuickStart.txt:

. . .
5. Open your own firewall ports.

If you need to make several ports accessible from WAN then create the text file
/overlay/etc/netwall.conf with ports you need to open. Example of this file:
------------------------------------------------------------------------
ACCEPT net fw tcp 22,8443
ACCEPT net fw udp 1194
------------------------------------------------------------------------
(to open TCP ports 22 and 8443 and UDP port 1194).

NOTE: this file should contain LF symbol at the end of last line (press ENTER key in
your text editor).
. . .


Voxel.

@Voxel or others - I understand I can open port 22 from WAN but that would expose the standard port + allow to authenticate with password.

I have figured out that `dropbear` cannot disallow password authentication (or root access) based on the listening port. I can add multiple listening ports (kill running `dropbear` and start my own with own CLI params) but all other params will apply regardless of the port.

Basically, I want to enable local port 22 with password (e.g. when I am home) but also remotely, only on 5422 and with a SSH key.

Can I run 2 `dropbear` concurrently ? Or if anyone as another idea...

 

[Voxel]

Or if anyone as another idea...

Another idea is to use authorization by key i.e. to create /root/.ssh/authorized_keys using "Overlay partition on USB" (QuickStart.txt) and changind dropbear init script disallowing login by password.

Change in /etc/init.d/dropbear file

. . .
$DROPBEAR -p $PORT -a -P $PIDFILE
. . .

to:

. . .
$DROPBEAR -p $PORT -a -s -P $PIDFILE
. . .

and use authorizatioin by key alsways keeping your own /root/.ssh/authorized_keys.



Voxel.

 

[yiga]

Thanks Voxel. So using same settings and access method for both LAN and WAN. That's probably the easiest indeed.

But you enabled password authentication in the FW at some point in the past so I thought there must have been a good reason for it e.g. key lost, no SSH anymore.
Even so, I can always access with telnet to regenerate keys.

Are custom files in etc/init.d boot safe, or should I copy them in post-mount.sh (or include in backup) ?

 

[L&LD]

Voxel, not 'Vowel'.

 

[yiga]

Voxel, not 'Vowel'.

Fixed

 

[Voxel]

But you enabled password authentication in the FW at some point in the past so I thought there must have been a good reason for it e.g. key lost, no SSH anymore.

I enabled password authorization for ORBI RBK50 only because there is a version of ORBI RBK50 v2 where there is no USB port at all, which creates certain difficulties for users. So, for example, for R7800/R9000/R8900 password authorization is disabled by default.

Are custom files in etc/init.d boot safe, or should I copy them in post-mount.sh (or include in backup) ?

They are not boot safe. Read please QuickStart.txt included into archive with firmware:

. . .​

2. Overlay partition on USB.​

​

Original stock firmware uses tmpfs overlay partition (in RAM). So all you changes in​

the files/dirs are kept only until next reboot of router/satellite. If you need to keep​

your changed/added files you should use external USB disk/stick formatted as​

ext2/ext3/ext4 with /overlay directory on the root where you should add your new or​

modified files keeping the dirtree of Orbi. For example, if you wish to use your own​

/etc/dnscrypt-proxy-2.toml just place it into /overlay/etc/dnscrypt-proxy-2.toml.​

. . .​

You just have to have your modified or added files in the /overlay directory on the USB disk. In your case it is

/mnt/sda1/overlay/root/.ssh/authorized_keys

and

/mnt/sda1/overlay/etc/init.d/dropbear

I have similar files for key authorization.

Voxel.

 

[yiga]

My bad. I had missed what exactly gets lost. Great for the overlay, no need to change scripts.

Thanks for the prompt reply and your commitment to support a great firmware. Keep tight.

 

[yiga]

@Voxel I want to see the logs from dropbear. I had read that by default it outputs to syslog but:

1. The UI (Logs in adv_index.htm) has no SSH details
2. no SSH info in /var/log/messages or in /tmp/mnt/sda1/entware/var/log/messages
3. running manually dropbear -E does output to stdout
4. -v flag is not recognized in v2022.83. Changelog though shows that it was (re)worked in 2022.82

Any thoughts ( + not sure it's the right thread) ?

Lastly, I really like to allow no keyfile when connecting from lan. Do you support configuration like this ?