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

Voxel

Very Senior Member
Continuation of

https://www.snbforums.com/threads/custom-firmware-build-for-orbi-rbk50-v-2-5-0-42sf-hw.60308/
. . .
https://www.snbforums.com/threads/c...50-v-9-2-5-1-33sf-hw-v-9-2-5-1-34sf-hw.65137/
https://www.snbforums.com/threads/c...50-v-9-2-5-2-5sf-hw-v-9-2-5-2-5-1sf-hw.66034/

New version of my custom firmware build: 9.2.5.2.6SF-HW.

Changes (vs 9.2.5.2.5.1SF-HW):

1. Toolchain: Go is upgraded 1.14.7->1.15.3.
2. Toolchain: binutils version is upgraded 2.35->2.35.1.
3. Toolchain: -finline-functions compiler option is added to GCC.
4. Kernel level acceleration (-O2, -march=armv7-a -> -mcpu=cortex-a7, -finline-functions, etc.).
5. wireguard package is upgraded 1.0.20200729->1.0.20200908.
6. Change kernel config and OpenSSL 1.1.1 to allow using dynamic devcrypto and afalg engines (HW version).
7. OpenSSL v. 1.1.1 package is upgraded 1.1.1g->1.1.1h.
8. OpenSSL v. 1.0.2 package: change default config directory.
9. Fix Smart Lock icon issue (WebGUI).
10. jansson package is upgraded 2.12->2.13.1.
11. libjson-c package is upgraded 0.14->0.15.
12. expat package is upgraded 2.2.9->2.2.10.
13. nano package is upgraded 5.2->5.3.
14. Change SAMBA config generation (for Android/iOS gadgets, issue reported by Rustypouch).
15. Make an order in samba36 Makefile.
16. logrotate package is upgrader 3.15.0->3.16.0.
17. cifs-utils package is upgraded 6.10->6.11.
18. iperf3 package is upgraded 3.8.1->3.9.
19. Fix proftpd issue: display size of large file (thanks to R. Gerrits).

The link is:

https://www.voxel-firmware.com (thanks to vladlenas for his help with hosting).

P.S. My README.1st and QuickStart.txt:

(!) IMPORTANT NOTE: it is strongly advised to update to the stock firmware 2.5.2.x
before flashing this version.


It is note for users who change stock firmware to my build. If you are using my build this "update to the stock firmware 2.5.2.x" is not needed of course.


Voxel.
 
Last edited:

theoak

Regular Contributor
As noted above by Voxel, I had Voxel 9.2.5.2.5.2 installed already. I upgraded to Voxel 9.2.5.2.6 directly without issue.
 

Skippy Bosco

Regular Contributor
It is not entirely clear in the messaging here or in the readme. It current states to update to stock firmware 2.5.2.x.

To be EVEN MORE CLEAR, if you are running 2.7 stock firmware or higher you MUST downgrade to a 2.5.2 or lower before flashing or you will soft brick your router and satellite and need to TFTP to recover.
 

NemesisXT

New Around Here
I also installed your latest firmware and had no issues.

Voxel, I need a recommendation. My current setup is one router, two satellites, and one outdoor Orbi unit. All the satellites are connected using the ethernet "wired" as the backhaul. Should I disable the Daisy Chain Topology option? Any benefits in disabling using my current configuration.

Thanks, and keep up the great work.
 

Skippy Bosco

Regular Contributor
I also installed your latest firmware and had no issues.

Voxel, I need a recommendation. My current setup is one router, two satellites, and one outdoor Orbi unit. All the satellites are connected using the ethernet "wired" as the backhaul. Should I disable the Daisy Chain Topology option? Any benefits in disabling using my current configuration.

Thanks, and keep up the great work.
This setting will not make a difference if you are using wired backhaul.
 

Skippy Bosco

Regular Contributor
Just finished the update that I've done the firmware upgrade to both my satellites and router (v1). Quick and painless process. Flashed satellites one at a time, then the router. Waited for everything to sync and back up and running. Whole thing took 5 minutes start to finish.

Fast. Stable.
 
Last edited:

boto

New Around Here
Could be more precise about this note please ?

(!) IMPORTANT NOTE: do not reset your RBK to factory default settings (flash the stock
version first to perform reset).

When I flash to major version, I usually reset my router/satellite to default setting.
In my case, I 'm running Stock 2.5.2.4. What I suppose to do to flash from factory ?
Regards
 

Skippy Bosco

Regular Contributor
Could be more precise about this note please ?

(!) IMPORTANT NOTE: do not reset your RBK to factory default settings (flash the stock
version first to perform reset).

When I flash to major version, I usually reset my router/satellite to default setting.
In my case, I 'm running Stock 2.5.2.4. What I suppose to do to flash from factory ?
Regards
Reset to factory default settings while still on stock 2.5.x, then do the manual update to Voxel.

If you try to factory reset while on Voxel (either via UI or by holding the reset button) it will soft brick your router and require you to TFTP stock back on via recovery mode.

Also, for now, always flash stock 2.5.x or older first before flashing to Voxel. If you try to update to Voxel from stock 2.7 you will soft brick your router and satellites.
 

boto

New Around Here
thanks for this precious precision and I saw UI doesn't permit this on Voxel :)

I doesn't see into GitHub new feature section so I post here.
I would be nice to unmask the auto-update firmware section in the GUI avoiding to revet back to stock ... (I personally was auto upgraded to 2.5.1.32 and don't like this :-( )

Regards

Capture d’écran 2020-10-20 à 13.29.25.png
 

Skippy Bosco

Regular Contributor
I would be nice to unmask the auto-update firmware section in the GUI avoiding to revet back to stock ... (I personally was auto upgraded to 2.5.1.32 and don't like this :-( )
One of the reasons for the numbering of the the Voxel releases (a 9.x before the stock version #) is to always be a newer version than stock to avoid conflict as well as prevent auto updating.
 

chiron

New Around Here
Hey Voxel,

Would it be possible in the future to be able to preserve configuration changes without a USB overlay? I just setup my entire /overlay on a ext4 formatted USB only to realize that I have an Orbi which doesn't have a USB Slot. I think their V2 models they removed the USB :rolleyes:
 

Voxel

Very Senior Member
Hey Voxel,

Would it be possible in the future to be able to preserve configuration changes without a USB overlay? I just setup my entire /overlay on a ext4 formatted USB only to realize that I have an Orbi which doesn't have a USB Slot. I think their V2 models they removed the USB :rolleyes:
There is no common solution with overlay for Orbi V2 w/o USB. There is however something like workaround, it was implemented by request of Orbi V2 owner, see my QuickStart.txt:

. . .
11. Custom script to run (for Orbi v2 owners, units w/o USB port).

You can create you own script to execute it after every reboot. Script should be placed
to /mnt/ntgr directory (internal nand) with name: rc.user. I.e.

/mnt/ntgr/rc.user
. . .


I.e. you can create the some own custom script (from telnet/ssh) /mnt/ntgr/rc.user which will do something for you after reboot. And to keep some config files there (/mnt/ntgr/). For example your own dnscrypt config. And script will stop dnscrypt, copy config from the above location, and start dnscrypt with your own config. Something like:

/mnt/ntgr/rc.user:
Code:
#!/bin/sh

/etc/init.d/dnscrypt-proxy-2 stop
cp -f /mnt/ntgr/my-dnscrypt-proxy-2.toml /etc/dnscrypt-proxy-2.toml
/etc/init.d/dnscrypt-proxy-2 start
According to guy who has such Orbi V2 this /mnt/ntgr is ubi block 40MB (different vs Orbi V1) so it survives reboot. Unfortunately it does not survive flashing new firmware as I guess... But it is possible to mount remote share from telnet/ssh and to perform backup e.g. to your Windows computer. Headache, I understand, but I do not have Orbi V2 to make some testing with this and to design something more good. Different layout of ubi/mtd blocks.

How to mount your remote share for backup or restore your configs (e.g. from Windows PC): see my QuickStart.txt.

All these above are just hints...

Voxel.
 
Last edited:

Julian Brooks

New Around Here
I have an issue upgrading to 9.2.5.2.6 from 9.2.5.2.5.2
I have and RBR50 and 2x RBS50s. Am running in AP mode. Everything was on 9.2.5.2.5.2. I have just upgraded one RSR50 and there is an issue with the IP address. I had fixed IPs set from my router. The satellite was 192.168.178.202 and now shows on the RBR50 connected satellite screen as 192.168.1.250 after the upgrade. I have now reset the fixed IP to DHCP in the router but the satellite refuses to pick up a new DHCP address. I have also turned the satelite off/on several times.

Does anyone have any advice please on how to resolve the issue?

Edit: releasing the fixed IP now shows a new IP 192.168.178.47 on the router but on the RBR50 it still shows 192.168.1.250 but consequently I can't connect back to the satellite. Strangely the RBR50 shows a good connection to the satellite.
 
Last edited:

Voxel

Very Senior Member
I have just upgraded one RSR50 and there is an issue with the IP address. I had fixed IPs set from my router.
RSR50 ---> RBS50.

"Fixed IP": Do you mean "LAN Address Reservation"? I have now two RBS50 and they are included into Address Reservation: as 192.168.x.251 and 192.168.x.252. After flashing 9.2.5.2.6 they are still accessible as 251 and 252.

I'd suggest you to delete your RBS from "Address Reservation" and add it anew. Maybe MAC is wrong in your settings or so. After that reboot your RBR/RBS.

All my reservations (17 items) are kept after flashing.

Voxel.
 

Julian Brooks

New Around Here
RSR50 ---> RBS50.

"Fixed IP": Do you mean "LAN Address Reservation"? I have now two RBS50 and they are included into Address Reservation: as 192.168.x.251 and 192.168.x.252. After flashing 9.2.5.2.6 they are still accessible as 251 and 252.

I'd suggest you to delete your RBS from "Address Reservation" and add it anew. Maybe MAC is wrong in your settings or so. After that reboot your RBR/RBS.

All my reservations (17 items) are kept after flashing.

Voxel.
Yes, LAN IP reservation for the Mac address of RBR50 each RBS50. I have no clue where the 192.168.1.250 address is coming from but this is what is reported on the connected satellite screen on the RBR50. This subnet is not in use on my network so assume it has come from either the satellite or RBR50, somehow.

Can you recommend the best stock version to flash back to as will do this on the RBR50 and RBS50 I have not upgraded. I have already power cycled everything to no avail. If stock firmware does not sort out upgraded RBS50 I will get stock back via recovery mode on the problem satellite.
 

Voxel

Very Senior Member
I have no clue where the 192.168.1.250 address is coming from
It is default address for Orbi RBS connected to RBR.

Can you recommend the best stock version to flash back to as will do this on the RBR50 and RBS50 I have not upgraded. I have already power cycled everything to no avail. If stock firmware does not sort out upgraded RBS50 I will get stock back via recovery mode on the problem satellite.
I do not quite understand what you need, sorry. If temporary flashing to stock for factory reset and back to my version: then stock V2.5.2.4. But any re-configuration (Address Reservation) could be done with my build, just FYI.

Voxel.
 

Julian Brooks

New Around Here
Ok, all good now.
The issue was that flashing the RBS50 from 9.2.5.2.5.2 to 9.2.5.2.6 caused the IP address of the satellite to be fixed at 192.168.1.250. This would not change until I disconnected the wired back-haul connection. Over a wifi back-haul it sorted itself out when it then picked up a sensible DHCP address from the main router. I have now reinstated the reserved IP and all is good and am back on the wired back-haul. Whether it was the RBR50 causing this or the RBS50 I don't know, but I have not had issues on previous Voxel firmware when upgrading. I do have reserved IP addresses for the Orbi router in AP mode and the satellites but don't understand why this should affect anything. The 192.168.1.250 must be something from the Orbis somewhere as it cannot come from my main router as it does not use that subnet, at all.

I'll upgrade the remaining satellite and then the RBR50 tomorrow.
 

Julian Brooks

New Around Here
Ok, all good now.
The issue was that flashing the RBS50 from 9.2.5.2.5.2 to 9.2.5.2.6 caused the IP address of the satellite to be fixed at 192.168.1.250. This would not change until I disconnected the wired back-haul connection. Over a wifi back-haul it sorted itself out when it then picked up a sensible DHCP address from the main router. I have now reinstated the reserved IP and all is good and am back on the wired back-haul. Whether it was the RBR50 causing this or the RBS50 I don't know, but I have not had issues on previous Voxel firmware when upgrading. I do have reserved IP addresses for the Orbi router in AP mode and the satellites but don't understand why this should affect anything. The 192.168.1.250 must be something from the Orbis somewhere as it cannot come from my main router as it does not use that subnet, at all.

I'll upgrade the remaining satellite and then the RBR50 tomorrow.
Everything now on 9.2.5.2.6 and no issues. Thank you 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