What's new

[Release] Asuswrt-Merlin 384.13 is now available

  • 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!

Status
Not open for further replies.
You can use a postconfig file:
/jffs/scripts/stubby.postconf (chmod to 755)
Code:
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_append "tls_min_version: GETDNS_TLS1_3" $CONFIG
pc_append "tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"" $CONFIG
pc_append "tls_ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"" $CONFIG
Restart Stubby: service restart_stubby
As Merlin says this may be overkill but you are welcome to try. Note that not all resolvers support TLS 1.3 so you could fail...
Note to @ShiZzO , I'll probably remove my config now that @RMerlin says it is overkill.

But for the curious, this is how I code for the min and max cipher settings in jffs/configs/stubby.yml.add file
Code:
tls_min_version: GETDNS_TLS1_2
tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"
tls_max_version: GETDNS_TLS1_3
tls_ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
 
Merlin any chance you will include the N66U for the next Merlin update?

None. I never migrated any of the older MIPS models to the NG branch, and have no intention in doing so.

Unfortunately, in my case Stubby uses version 1.2 by default for Cloudflare servers -

How are you checking that?
 
Latency matters

When it comes to networking applications, latency is generally more important than throughput. A slightly slower throughput won't affect performance, but a slightly higher latency might have a major impact on time-critical services such as VoIP or gaming.
 
384.13 installed on three RT-AC86U routers. All running smoothly. I know the CPU temperature issue is supposed to only affect the AX88U, but I monitored before and after on all my AC86Us, and there is some indication of a slight temperature increase, perhaps as much as 3 deg C. CPU loads are unchanged.
 
How are you checking that?
Thanks for the fast reply. Via this command:

echo | openssl s_client -verify on -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853

Its showed everythime:

SSL-Session:
Protocol : TLSv1.2

Thank you.
 
echo | openssl s_client -verify on -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
use the openssl11 command (with TLS 1.3).
 
Can we remove the "Automatic Bandwidth Setting" from Adaptive QoS since it doesn't work in practice? Or at least put a note? I have been using Merlin for years and didn't know this until i found out by luck when dived deeper into QoS.
 
Upgraded to 384.13 on Thursday, everything seemed OK.
Went on vacation Friday, all went to sh!te.
My Router hung, no emails from my cameras, could not VPN in. Person seeing to my cats, had no internet.

Came home a couple of hours ago and I had to hit the reset button. it was the only thing I could do to gain access to it.
Now I will wait before adding the usual, Skynet, Diversion back on. USB drive has been disconnected and I will reformat before reconnecting it.
 
Can we remove the "Automatic Bandwidth Setting" from Adaptive QoS since it doesn't work in practice? Or at least put a note? I have been using Merlin for years and didn't know this until i found out by luck when dived deeper into QoS.

It's part of the stock firmware, it's not my code.

Thanks for the fast reply. Via this command:

In addition to the fact that you are testing with the wrong openssl version, that does not tell you how Stubby is connecting. You will need to do packet captures to determine the TLS version used by Stubby - and it should be TLS 1.3 without the need for the config changes.
 
Upgraded to 384.13 on Thursday, everything seemed OK.
Went on vacation Friday, all went to sh!te.
My Router hung, no emails from my cameras, could not VPN in. Person seeing to my cats, had no internet.

Came home a couple of hours ago and I had to hit the reset button. it was the only thing I could do to gain access to it.
Now I will wait before adding the usual, Skynet, Diversion back on. USB drive has been disconnected and I will reformat before reconnecting it.
Moral of the story here is don't make a significant change to your environment the day before going on holiday
 
When it comes to networking applications, latency is generally more important than throughput. A slightly slower throughput won't affect performance, but a slightly higher latency might have a major impact on time-critical services such as VoIP or gaming.
Precisely!!! :)

Consider the use cases such as High Performance Computing or High-Frequency Trading or Machine Learning or Advanced Analytics. Nanoseconds and microseconds matter greatly! We look at the time required for packets to hop from one switch to another b/c there are billions of them per second. It all adds up! Or consider my favorite case. When I can take $1M of servers and run 30-40% more workload by turning off all that balanced power stuff! That's a very real case which averted easily $300-$400K in added capital costs! Why b/c I would have needed to buy 30-40% MORE servers to do the same workload! BTW, the power argument fails miserably b/c I can buy a lot of power (15-20 years worth) to run those original 9 a very long time with $300-$400K !! ;)

I'm leaning toward tuning all the power items shown in the earlier posting off b/c that stuff about green ports and the Ethernet controllers is the same darn thing. Every subsystem in our machines is trying to sleep and that becomes highly detrimental to overall performance b/c -> Latency Matters.

I agree, YMMV! ONLY the most adventurous in these forums should change the defaults ASUS has chosen. Understanding what that means is good info for everyone though! Peace.

This is wandering off topic so if someone wants to PM me that's fine or start a new thread. Later.
 
Thank you Eric for the new release.

I was about to flash it, but one of your comments had me puzzled:

Note for developers, the dhcp_staticlist format was changed to revert back to the same format as stock firmware (for AiMesh compatibility). The hostname field was moved to a separate variable, dhcp_hostnames. Note that this variable will be stored in a jffs file on the RT-AC86U and RT-AX88U due to limitations on variable length for their HND platform. That means that a backed up config file will not restore these hostnames when restored (but using a JFFS backup will).

Should I infer from it that flashing .13 and then restore JFFS from previous (.12) version would generate the 'dhcp_staticlist' and 'dhcp_hostnames' files in the NVRAM ?

Sorry for the dumb question, but I recall fondly john9527's back up/restore tools for previous mods, which made upgrading a breeze. Since then I have relied on get / set dhcp_staticlist to somehow ease the pain. Not wanting to go nuclear either...
 
Should I infer from it that flashing .13 and then restore JFFS from previous (.12) version would generate the 'dhcp_staticlist' and 'dhcp_hostnames' files in the NVRAM ?

384.12 had both IPs and hostnames stored in the same location (dhcp_staticlist). When you boot 384.13, it checks if dhcp_staticlist entries contain two or three parameters. If there are three, then it will split the data into dhcp_staticlist and dhcp_hostnames. So, restoring a 384.12 JFFS backup while on 384.13 with an RT-AC86U or RT-AX88U will cause the conversion process to be re-applied again.

You should make a fresh JFFS backup after updating to 384.13 if you are on an RT-AC86U or RT-AX88U. All other models store both variables in nvram.
 
And obviously, going from 384.13 back to 384.12 will cause you to lost all your static hostnames...
 
Thank you, I think I got it.

I will dirty upgrade, flashing 384.13 without 'erasing JFFS at next reboot', get the dhcp_staticlist and dhcp_hostnames stored somewhere, do all the clean install work, and then re set both of them (and the rest of the config), under a clean 384.13 mod.
 
Precisely!!! :)

Consider the use cases such as High Performance Computing or High-Frequency Trading or Machine Learning or Advanced Analytics. Nanoseconds and microseconds matter greatly! We look at the time required for packets to hop from one switch to another b/c there are billions of them per second. It all adds up! Or consider my favorite case. When I can take $1M of servers and run 30-40% more workload by turning off all that balanced power stuff! That's a very real case which averted easily $300-$400K in added capital costs! Why b/c I would have needed to buy 30-40% MORE servers to do the same workload! BTW, the power argument fails miserably b/c I can buy a lot of power (15-20 years worth) to run those original 9 a very long time with $300-$400K !! ;)

I'm leaning toward tuning all the power items shown in the earlier posting off b/c that stuff about green ports and the Ethernet controllers is the same darn thing. Every subsystem in our machines is trying to sleep and that becomes highly detrimental to overall performance b/c -> Latency Matters.

I agree, YMMV! ONLY the most adventurous in these forums should change the defaults ASUS has chosen. Understanding what that means is good info for everyone though! Peace.

This is wandering off topic so if someone wants to PM me that's fine or start a new thread. Later.

Your post is interesting and, I agree, probably off topic (so why do I reply? sorry moderators...).
Can we get less latency without resorting to using more power? So far HFT and the likes have gone the old route: get your machines as close as you can to the exchange...
It took 200+ years to prove Principia Mathematica inaccurate, and just 50 for Moore's law. It will probably take half of that to have the Amazon forest wiped out. And while we are -quite rightly so, if you ask me- concerned about our routers' CPUs jumping 10 degrees Celsius, well ermm, the permafrost is melting.
Definitely off-topic.
 
Having some trouble with 5Ghz network, I have smart connect, but my phone wont connect to 5Ghz, and I'm close to router. Both 2.4 and 5 Radio is enabled.

I did factory reset after flashing and turned off router after that and disconnect it from the power and wait 20 sec. but no changes.


EDIT:
Restarted the phone, and now it's ok. I'm just wondering is this phone issue or something with router...

I did some test today and something is not right with smart connect. It's not switching to 5Ghz as before, I have to turn off wifi on my phone and turn in back On to get 5Ghz, and I am in close range to router. Before this flash it was working normally, when I went out of 5Ghz range it will switch to 2.4Ghz and when I get back in range of 5Ghz it would auto. switch to 5Ghz, without any trouble of switching.
 
There is absolutely no temperature rise on the AC86 and this new version. For me it has always been the same. 61c idle and the room temp is 22c, and it's like that since I have this router.(2 years)
Guys, stop focusing on your temps :D:p
 
Upgrade RT-AC3100 from V384.12_0 Final to V384.13_0 Final, via dirty firmware upgrade, and everything is working great!
 
Status
Not open for further replies.

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top