Custom firmware build for R9000 v. 1.0.4.30HF/1.0.4.30HF-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/
https://www.snbforums.com/threads/custom-firmware-build-for-r9000-v-1-0-4-29hf-1-0-4-29hf-hw.55877/

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

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

1. ffmpeg package is upgraded 3.4.5->3.4.6.
2. cifs-utils package is upgraded 6.8->6.9.
3. wget package is upgraded 1.20.1->1.20.3.
4. sqlite package is upgraded 3260000->3270200.
5. getdns package (used in stubby) is upgraded 1.5.0->1.5.2.
6. stubby package is upgraded 0.2.4->0.2.6.
7. DNSCrypt Proxy v.2 is upgraded 2.0.22->2.0.23.
8. curl package is upgraded 7.64.0->7.64.1.
9. HW version: mbedtls package is upgraded 2.16.0->2.16.1.
10. libusb package is added (v. 1.0.22).
11. libusb-compat package is added (v. 0.1.5).
12. mp707 package is added (v. 1.0.2-20171025).
13. Typo bug in OpenVPN client (led control in ovpnclient-down.sh script) is fixed.
14. congestion control algorithm is changed to westwood+.
15. rmem_max/wmem_max/defaults values are decreased to avoid bufferbloat issues (note: use QoS and limit your max speed for good results in dslreports).
16. DNSCryps Proxy V1 and its dependence libsodium are removed.
17. net-wall: cosmetic changes.
18. cmdftp: cosmetic changes.
19. Host tools: now default host cmake is used.

The link is:

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

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

Voxel.

 

[Gar]

Thanks for your work on this project Voxel!

 

[Voxel]

Thanks for your work on this project Voxel!

It is just interesting.

Voxel.

 

[kc6108]

@Voxel

I see you changed the TCP Congestion Control Algorithm to Westwood+. Did you happen to perform any benchmarking, testing, etc between some of the different algorithms? Do you happen to know what flavor Netgear usually implements in their routers? BIC, CUBIC, YeAH-TCP, etc?

 

[Voxel]

@Voxel

I see you changed the TCP Congestion Control Algorithm to Westwood+. Did you happen to perform any benchmarking, testing, etc between some of the different algorithms? Do you happen to know what flavor Netgear usually implements in their routers? BIC, CUBIC, YeAH-TCP, etc?

It is done for unification with R7800 codes. Well, rather my own benchmarks for my own needs ;-) But users of my firmware are free to chose their congestion control algorithm using upcoming release of the add-on from kamoj or right now from telnet.

NG is using CUBIC. For all routers I played with: R7500, R7500v2, R7800, R9000 and even Orbi (checking its code).

P.S.
I changed to Westwood+ because it is pretty good for LTE connection. I have to use one of my R7800 with LTE modem. Second R7800 (fiber optic connection) always gives me A+ with dslreports. Does not matter: YeAH or Westwood+. At least:

https://www.snbforums.com/threads/custom-firmware-build-for-r7800-v-1-0-2-66sf.56631/#post-491844

means that it Westwood+ is OK for others too.

P.P.S.
Quote from one article:

Comparing the congestion control algorithms to each other
shows that whilst some of the algorithms can co-exist, others
cannot. TCP-Vegas consistently had a low mean throughput
of about 10 Mbps against all other TCP variants. TCP-Vegas
is perhaps the algorithm that is most sensitive to network
congestion, as it gives up bandwidth the most easily.
The most aggressive algorithms are HTCP, Westwood, Illinois,
BIC and Scalable. Of these four, Westwood is the most
greedy, taking nearly all available bandwidth for itself. It is
perhaps the most insensitive to congestion on the network.
YeAH, HighSpeed, LP, Hybla, Reno, CUBIC, and Reno
share the available bandwidth more or less equally among
themselves.

Voxel.

 

[Olivier]

Installed & running smoothly. Except for dnscrypt where I had to enable & start the process.

 

[Voxel]

Except for dnscrypt where I had to enable & start the process.

It is strange because dnscrypt v2 enable options is kept in nvram. And nvram settings are restored after flashing automatically. I did not re-enable dnscrypt for my R9000 after flashing...

Voxel.

 

[Olivier]

It is strange because dnscrypt v2 enable options is kept in nvram. And nvram settings are restored after flashing automatically. I did not re-enable dnscrypt for my R9000 after flashing...

Voxel.

I will take care before the upgrade when you will release a new version

 

[multicast]

Thank you @Voxel, is there any chance you can post the contrab -l output? I customized mine and in a mistake when I did the upgrade I didn't check what was the default one.

 

[Voxel]

Thank you @Voxel, is there any chance you can post the contrab -l output? I customized mine and in a mistake when I did the upgrade I didn't check what was the default one.

crontab -l

48 04 * * * /TM/QoSControl auto_update
0 3 * * * /etc/plexmediaserver/plexmediaserver_upgrade.sh auto_sched_update>/dev/console
*/10 * * * * sync; echo 3 > /proc/sys/vm/drop_caches

BTW, it is always possible to restore original files. Check the /rom directory.

Command:

cp -p -f /rom/etc/crontabs/root /etc/crontabs
rm -f /overlay/etc/crontabs/root

something like this.

I.e. oroginal files are in /rom directory.

cat /rom/etc/crontabs/root

48 04 * * * /TM/QoSControl auto_update
0 3 * * * /etc/plexmediaserver/plexmediaserver_upgrade.sh auto_sched_update>/dev/console
*/10 * * * * sync; echo 3 > /proc/sys/vm/drop_caches

i.e. the same output.

Voxel.

 

[multicast]

crontab -l

48 04 * * * /TM/QoSControl auto_update
0 3 * * * /etc/plexmediaserver/plexmediaserver_upgrade.sh auto_sched_update>/dev/console
*/10 * * * * sync; echo 3 > /proc/sys/vm/drop_caches

BTW, it is always possible original files. Check the /rom directory.

Command:

cp -p -f /rom/etc/crontabs/root /etc/crontabs
rm -f /overlay/etc/crontabs/root

something like this.

I.e. oroginal files are in /rom directory.

cat /rom/etc/crontabs/root

48 04 * * * /TM/QoSControl auto_update
0 3 * * * /etc/plexmediaserver/plexmediaserver_upgrade.sh auto_sched_update>/dev/console
*/10 * * * * sync; echo 3 > /proc/sys/vm/drop_caches

i.e. the same output.

Voxel.

THANK YOU! @Voxel!

 

[multicast]

@Voxel I did just upgraded mine with this release, have to admit I see better throughput than before. At least videos load faster and don’t get “stuck”. Wonder if the new congestion protocol did this. I have 1Gbps BW without QoS enabled.

 

[Voxel]

Wonder if the new congestion protocol did this

Rather both: "14" and "15":

14. congestion control algorithm is changed to westwood+.
15. rmem_max/wmem_max/defaults values are decreased to avoid bufferbloat issues

Voxel.

 

[multicast]

Rather both: "14" and "15":


Voxel.

14 even without having QoS enabled?

 

[multicast]

14 even without having QoS enabled?

Really great performance for this release @Voxel, thank you very much!

Would it be better than this if I use QoS?

 

[Voxel]

14 even without having QoS enabled?

Yes.

Would it be better than this if I use QoS?

I do not think so. Your speed is practically maximal and QoS is not needed for your.

Voxel.