[Beta] Asuswrt-Merlin 384.10 Beta is now available

[EricLinTW]

Taiwan version AX88U AICloud can't connect on lan or wan.
I already try to change port(any port),but still get "err_connection_refused"
And other version (384.9,384.8_2) also with this problem.
On official FW 3.0.0.4.384.5640 Aicloud Working normally.
On AC86U 384.2 384.9 there work perfect.This problem only with AX88U.

 

[Howard_inGA]

RT-AC5300 dirty upgrade from alpha to new beta...flawless!

 

[pietjepuk100]

Dirty upgrade from 384.9 to 384.10 Beta1. So far so good.

Thanks Eric!

 

[dugaduga]

The last alpha & latest beta sits on "vpn connecting" but does not get past that. ISP or firmware? ISP/Govt was blocking my dnscrypt servers recently; it worked momentarily after a reboot. ill revert to the previous version and see what happens

 

[dugaduga]

Its not working on 384.9 either, so suspect its probably the govt of Canada, that tends to happen here if you are opposed to Al-Qaeda.

 

[thiggins]

Please keep politics out of the discussion.

 

[faria]

(RT-AC86U)
Anyone else having problems with asus DDNS on this build ?
Logs show Authentication errors .
/tmp/inadyn.cache/ folder empty.
Internet status reports all fine .
Tanks @RMerlin for all you hard work.

 

[jerry6]

seems good no problems yet m though still ud-sing 128 mb of ram after a manual reboot instead of the 68mb ram used pre 384 . wil give the https a try , hope it works well . thanks for the fw .

 

[AntonK]

Hi,

Does anyone know if these QOS log entries are something to be concerned with? The last one seems to be from yesterday, with nothing on the 11th+

Thanks,
Anton

Mar 10 20:33:35 rc_service: httpd 305:notify_rc start_sig_check
Mar 10 20:33:51 BWDPI: fun bitmap = ff
Mar 10 20:33:51 A.QoS: qos_count=0, qos_check=0
Mar 10 20:33:54 A.QoS: qos rule is less than 22
Mar 10 20:33:54 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Mar 10 20:33:55 A.QoS: qos_count=0, qos_check=1
Mar 10 20:33:58 A.QoS: qos rule is less than 22
Mar 10 20:33:58 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Mar 10 20:33:59 A.QoS: qos_count=1, qos_check=1
Mar 10 20:34:02 A.QoS: qos rule is less than 22
Mar 10 20:34:02 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Mar 10 20:34:04 A.QoS: qos_count=2, qos_check=1
Mar 10 20:34:07 A.QoS: qos rule is less than 22
Mar 10 20:34:07 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail

 

[jerry6]

had trouble getting to any sitesusing https would not load any pages , got timeout errors with 3200 using 384.10

 

[skeal]

Does anyone know if these QOS log entries are something to be concerned with?

Nope another Asus thing.

 

[AntonK]

Nope another Asus thing.

Thanks!

 

[Swistheater]

yea I've seen the same QOS log issues, but I have not notice it effecting the performance of the overall QOS though. No IPSEC or openvpn issues so far. update from 384.10alpha2 to beta 1 went flawless w/out having to factory reset. I did have alittle issues with the ddns authentication, but after waiting a few hours and switching it from no cert back to letsencrypt, I had no issues.

 

[RMerlin]

Does anyone know if these QOS log entries are something to be concerned with? The last one seems to be from yesterday, with nothing on the 11th+

They're normal. The Adaptive QoS init code will create a bunch of rules, then will periodically check the number of created rules to determine if it's done creating them all or not. It's just debugging output Asus left in there.

had trouble getting to any sitesusing https would not load any pages , got timeout errors with 3200 using 384.10

Unrelated to the firmware, as from the router's point of view https traffic is just like any other types of traffic.

Check the clock on your computer - an inaccurate clock (for instance if it didn't properly update this weekend) will prevent https connections from working properly.

 

[RMerlin]

No IPSEC

What client are you using? I had to re-enable some legacy ciphers for Android's native client to work with the updated Strongswan (Android's IKEv1 client won't allow newer ciphers), just wasn't sure that other clients might also have their own special requirements for IKEv1 support.

 

[RMerlin]

Taiwan version AX88U AICloud can't connect on lan or wan.
I already try to change port(any port),but still get "err_connection_refused"
And other version (384.9,384.8_2) also with this problem.
On official FW 3.0.0.4.384.5640 Aicloud Working normally.
On AC86U 384.2 384.9 there work perfect.This problem only with AX88U.

Confirmed, the lighttpd modules are missing for the RT-AX88U build.

 

[jerry6]

They're normal. The Adaptive QoS init code will create a bunch of rules, then will periodically check the number of created rules to determine if it's done creating them all or not. It's just debugging output Asus left in there.

thanks think th clock thing hit it , iy-t did not update
thanks

Unrelated to the firmware, as from the router's point of view https traffic is just like any other types of traffic.

Check the clock on your computer - an inaccurate clock (for instance if it didn't properly update this weekend) will prevent https connections from working properly.

 

[jerry6]

ive got this message and nothing i do gets rid of it , not sure what to do
message
"Change the router login password, time zone, and NTP server settings."
how to change ntp settings , really no clue, changed all the rest , no diff

 

[JohnSmith]

Upgrade AX88U from V384.9_Final to V384.10_Beta1, via dirty flash. All appears to be working, except for the following ASUS issue (NOT RMerlin's, as noted in his Changelog).

• Networkmap listing may be unreliable. (Bug in Asus's code) - RMerlin's Changelog

Also, running FreshJR QOS V8.8 and his Classification Tab, and after the firmware upgrade, noticed two things on the RT-AX88U:

• Under "Adaptive QOS" | "QOS", noticed my "Customize" button was no longer selected "blue in color", and that some of the categories were moved out of order from what I had set them before
• Under "Adaptive QOS" | "Bandwidth Monitor", any of my "Network Map" List clients that I normally had set from "Highest" to "Lowest" were all back to "Default" color

Not sure if this is an issue or not, but just relaying firmware upgrade info, since, once I re-customized my categories, and applied the "Highest" to "Lowest" again on my Network Map List, everything is running properly again.

 

[Swistheater]

What client are you using? I had to re-enable some legacy ciphers for Android's native client to work with the updated Strongswan (Android's IKEv1 client won't allow newer ciphers), just wasn't sure that other clients might also have their own special requirements for IKEv1 support.

I am using an android client, but I don't know what you did merlin, but before a couple of flashes ago, the IPsec would take the longest to connect into, now I connect into it with the ease of a tap. Whatever you did has made it better from my opinion.