Custom firmware build for R9000 v. 1.0.4.29HF/1.0.4.29HF-HW

[Voxel]

Continuation of:

https://www.snbforums.com/threads/custom-firmware-build-for-r9000.40125/
. . .
https://www.snbforums.com/threads/custom-firmware-build-for-r9000-v-1-0-4-27hf-1-0-4-27hf-hw.55117/

New version of my custom firmware build: 1.0.4.29HF/1.0.4.29HF-HW.

Changes (vs 1.0.4.27HF/1.0.4.27HF-HW):

1. Integration of changes from the stock v. 1.0.4.28.
2. dropbear package is upgraded 2018.76->2019.78.
3. OpenSSL package is upgraded 1.0.2q->1.0.2r.
4. OpenVPN is upgraded 2.4.6->2.4.7.
5. DNSCrypt Proxy v.2 is upgraded 2.0.19->2.0.22.
6. unbound package (used in stubby) is upgraded 1.9.0->1.9.1.
7. ca-certificates package is upgraded 20180409->20190110.
8. libubox package is upgraded 2018-11-16->2019-02-27.
9. tar package is upgraded 1.31->1.32.
10. libgpg-error package is upgraded 1.34->1.36.
11. busybox package: dos2unix/unix2dos commands are added.
12. proftpd: read access issue for admin user is fixed (NG bug).
13. Toolchain: binutils version is upgraded to 2.32.

The link is:

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

Difference 1.0.4.29HF-HW vs 1.0.4.29HF: “HW” version means hardware acceleration of OpenSSL.

Voxel.

 

[multicast]

Thanks @Voxel for your work on this, anything in particular that would improve between .27 and .29? Just want to be sure if worth to upgrade though

 

[L&LD]

Thanks @Voxel for your work on this, anything in particular that would improve between .27 and .29? Just want to be sure if worth to upgrade though

Thirteen reasons to upgrade in post 1 above.

 

[Voxel]

Thirteen reasons to upgrade in post 1 above.

Yeah

Thanks @Voxel for your work on this, anything in particular that would improve between .27 and .29? Just want to be sure if worth to upgrade though

Well, reasons to upgrade, most important IMO are:

"2."-"4." Mainly security fixes. Safety of your data and surfing, keeping privacy.

"1." Integration of changes from the stock v. 1.0.4.28 i.e.

https://kb.netgear.com/000060645/R9000-Firmware-Version-1-0-4-28

• New functionality: added support of DHCP auth options 60 and 61 from GUI (what was long-awaited by many owners of R9000)
• QoS DB updates.

"12." Repairing broken functionality (FTP).

Many people do not need or do not use such functionality as QoS or DHCP options 60/61 or FTP but security fixes are important for everybody. Even if you do not use, say, dropbear (SSH).

Voxel.

 

[kc6108]

@Voxel

I'm running into some playback issues with some media files I created several months back. I'm told ffmpeg v3.4.6 is needed to address the errors. Would you try to fit in an upgrade to ffmpeg with your next firmware release please?

Thanks

 

[Voxel]

@Voxel

I'm running into some playback issues with some media files I created several months back. I'm told ffmpeg v3.4.6 is needed to address the errors. Would you try to fit in an upgrade to ffmpeg with your next firmware release please?

Thanks

Sure. It is released only 5 days ago. So for the next release.

Voxel.

 

[Mark M]

Not looking to cause waves, but just throwing a fair warning out there. Firmware 1.0.4.28 could potentially brick the R9000.

Netgear is looking into it as of 3/21/19 according to this post: https://community.netgear.com/t5/Ni...-or-you-ll/m-p/1724826/highlight/true#M124793

Not sure what "brick" the OP in the Netgear forums is referring to. My best guess is similar to the R7800 issue of "rebooting router restores to factory defaults" (AKA, settings do not stick on a reboot). I recall seeing other posts on the Netgear forums with similar symptoms.

On a side note, one may never have an issue with the latest firmware. Could always be potentially faulty hardware coming to light. To each his own

 

[xTe22-pT]

Not looking to cause waves, but just throwing a fair warning out there. Firmware 1.0.4.28 could potentially brick the R9000.

Netgear is looking into it as of 3/21/19 according to this post: https://community.netgear.com/t5/Ni...-or-you-ll/m-p/1724826/highlight/true#M124793

Not sure what "brick" the OP in the Netgear forums is referring to. My best guess is similar to the R7800 issue of "rebooting router restores to factory defaults" (AKA, settings do not stick on a reboot). I recall seeing other posts on the Netgear forums with similar symptoms.

On a side note, one may never have an issue with the latest firmware. Could always be potentially faulty hardware coming to light. To each his own

Oh damn ! Looks like I was a lucky one, cause I just have installed latest firmware version (1.0.4.29) and everything is running smooth on my end
Thanks for bringing up this thread here !

 

[Voxel]

Not looking to cause waves, but just throwing a fair warning out there. Firmware 1.0.4.28 could potentially brick the R9000.

Netgear is looking into it as of 3/21/19 according to this post: https://community.netgear.com/t5/Ni...-or-you-ll/m-p/1724826/highlight/true#M124793

Not sure what "brick" the OP in the Netgear forums is referring to. My best guess is similar to the R7800 issue of "rebooting router restores to factory defaults" (AKA, settings do not stick on a reboot). I recall seeing other posts on the Netgear forums with similar symptoms.

On a side note, one may never have an issue with the latest firmware. Could always be potentially faulty hardware coming to light. To each his own

Of course I do check all of my releases before publishing. Flashing to my R9000 many times. There were really some changes on the kernel level (stock 1.0.4.28). Usually exactly such changes could be a reason for bricking. But they (changes) are not dangerous. No any danger to flash my version, I am sure.

Also I have a bit different layout of mtd blocks vs stock fw (more safe IMO).

And BTW it is not so fatal to brick your R9000: I did it many times . It is hard to kill it by flashing firmware because of u-boot. So if you brick it: use tftp procedure. Not so difficult. No additional equipment is needed. u-boot will continue to work after bricking.

Voxel.

 

[Mark M]

Of course I do check all my releases before publishing. Flashing to my R9000 many times. There were really some changes on the kernel level (stock 1.0.4.28). Usually exactly such changes could be a reason for bricking. But they (changes) are not dangerous. No any danger to flash my version, I am sure.

Also I have a bit different layout of mtd blocks vs stock fw (more safe IMO).

And BTW it is not so fatal to brick your R9000: I did it many times . It is hard to kill it by flashing firmware because of u-boot. So if you brick it: use tftp procedure. Not so difficult. No additional equipment is needed. u-boot will continue to work after bricking.

Voxel.

Ahh, Did not know this. Good to be reassured.

Thank you Voxel!

 

[Voxel]

Thank you very much for continuing to update and giving some love to the R8900. I appreciate it.

Thank you
QuattroCS

I understand that you mean 1.0.4.29HF-HW for R8900. So it is better to use this thread.
Yes, I keep its support but I do not have possibility to test (I do not have R8900 unit). There are no any differences in fw R8900 vs fw R9000 firmware except QoS.

Voxel.

 

[Olivier]

Few days installed & working smoothly. No issue. Thanks!

 

[Voxel]

For some reason my VPN wont start with the update.
I've attached an image from the debug page.

Most probably you did not restore your ovpn file after flashing (i.e. your OpenVPN config). At least your error screenshot displays such information. So you should restore your ovpn config file.

Voxel.

 

[Voxel]

by "Restoring your .ovpn config file" do you mean putting it on the usb stick and then into the router? because i have already tried this. I even reset the router to factory and put both the .ovpn file and auth.txt on usb and still same issue. Am i missing something?

Try to copy it manually and check that it is in in proper place. From your USB:

        mkdir /etc/openvpn/config
        mkdir /etc/openvpn/config/client
        cp /mnt/sda1/openvpn-client/* /etc/openvpn/config/client
        chmod 0644 /etc/openvpn/client/*
        ll /etc/openvpn/config/client

Voxel.

 

[Voxel]

Ok i'm not an expert so i will just make sure i know what you have explained:
Put files on to usb and insert into router (will sda1 change depending on usb slot used?)
open debug page and enable telnet
log into router via telnet
issue above commands?

Yes, I mean exactly what you write. Just use your already prepared USB with OpenVPN client config and run these above commands (I assume that your OVPN file(s) are on USB in the folder \openvpn-client

Also check that attached USB will be mounted as /mnt/sda1 (in my commands). There could be other points: /mnt/sdb1 or /mnt/sdc1 etc. Command "mount" shows all mounted devices.

Voxel.