What's new

Voxel Custom firmware build for Orbi RBK50/RBK53 (RBR50, RBS50) v. 9.2.5.2.10SF-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!

translation?

Voxel referenced an updated build and linked to a post containing a changelog of the updates.

You asked generically if an update existed to fix "the issue" of which the majority of users are not experiencing, and those that are are running various versions of stock in addition to a small number running various versions of Voxel (ie. not specific to any stock or Voxel firmware version)

A user responded indicating a specific change in the updated Voxel which might have a positive impact in your environment which is in regards to disabling acceleration of certain encryption as in some rare situations it may cause conflict with QCE ( Qualcomm Crypto Engine ) ..

No one can say for sure since your issue is unique to your environment (ie. it is not a common problem that every user using Voxel or stock is experiencing)..
 
Last edited:
my guess would be :
13. Disable ARM/NEON acceleration (kernel crypto AES/SHA1) to avoid conflicts with QCE.
Absolutely correct guess.

So @digital10 : it has a sense for you to test 11SF-HW.

Details if you are interested.


NEON acceleration could introduce additional interruptions (kernel level). Plus ARM/NEON kernel crypto have the same priority as QCE. Not reproducible in my environment but could be the reason for your troubles.

Voxel.
 
Absolutely correct guess.

So @digital10 : it has a sense for you to test 11SF-HW.

Details if you are interested.


NEON acceleration could introduce additional interruptions (kernel level). Plus ARM/NEON kernel crypto have the same priority as QCE. Not reproducible in my environment but could be the reason for your troubles.

Voxel.

I will give it a shot, I am on 9.2.5.2.7 everything stable and working amazing no issues. I can not explain the different behaviors I am experiencing.

Do you know if flashing different firmwares causes issues , or residue files, because I really would hate to downgrade to official netgear->reset to factory settings-> then update again and having the router restart for every single thing I change in the settings.
 
I will give it a shot, I am on 9.2.5.2.7 everything stable and working amazing no issues. I can not explain the different behaviors I am experiencing.

Then why do anything if you are stable?

Do you know if flashing different firmwares causes issues , or residue files

There will always be residual / legacy cruft when migrating from version to version as old configuration is deprecated. That said, since the updated versions of Voxel of late are based on the same version of stock firmware (since that is the last GPL released version) there is less risk of that happening.

I really would hate to downgrade to official netgear->reset to factory settings-> then update again and having the router restart for every single thing I change in the settings.

If factory resetting is that impactful because of "every single change" you have to make post reset, you should really take a step back and reconsider just reverting to default settings and sorting out any environmental changes that need to happen instead of trying to mask them with router changes. In the long run it will make for a more consistent and stable environment.
 
I updated to .11 . So far so good. If I find an instabilities I will go back to .7 and report back just out if interest of Voxel, maybe he would like to know for some reason.

I am really having ideas that this instability is due to the dumb DHCP of netgear. Things seems more stable since I moved it to the PiHole side. The DHCP would literally list "connect devices" of things that are actually turned off. I have also seen it listing 2 devices with same IP. Last thing I noticed is that it had the Satellite as "disconnected" meanwhile I can access the PiHole that was attached to it via ethernet. It was ON and working for sure !

side annoyance, I dont think this has anything to do with Netgear or Voxel but my iPhone keeps switching from 3 Wifi bars, to 2, to 3 back again all the time although I am sitting in the same place. Any idea why it does this? Macbook in the same place does not do this.

Then why do anything if you are stable?



There will always be residual / legacy cruft when migrating from version to version as old configuration is deprecated. That said, since the updated versions of Voxel of late are based on the same version of stock firmware (since that is the last GPL released version) there is less risk of that happening.



If factory resetting is that impactful because of "every single change" you have to make post reset, you should really take a step back and reconsider just reverting to default settings and sorting out any environmental changes that need to happen instead of trying to mask them with router changes. In the long run it will make for a more consistent and stable environment.

1) You are correct, but I updated because I think I am supposed to get the latest security updates and latest updates are supposed to be the best version of any software...supposedly.

2)Some changes are necessary in the router settings. Guest network, SSID, DNS servers, UPnP OFF(security), Diasy Chain off(satellite setup in star-shape), IP reservation...etc
 
2)Some changes are necessary in the router settings. Guest network, SSID

Yes to those.

DNS servers, UPnP OFF(security), Diasy Chain off(satellite setup in star-shape), IP reservation...etc

These are mostly unnecessary during stability testing.

DNS should be derived automatically from your ISP.. if you are manually configuring a local or 3rd party immediately you are really invalidating your stability testing.

Disabling UPnP, given this just happens on your LAN, if you have devices attached to your LAN you don't trust that would be a better place to start in removing or hardening the device itself.

Daisy chain, let the network decide what is best in terms of this config. Adjust it after your stability testing is complete.

IP reservations, again let the system work in its own way. Use DHCP and if there is a device that does not play well in that setup, address it at the device level not the router level.. at least during stability testing for a week or so.
 

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