Release Asuswrt-Merlin 386.4 is now available

[Wycleff]

I use Asuswrt-Merlin 386.4 since release and today I noticed a sudden internet failure.
"Internet status: Not connected" is displayed since then and it cannot be fixed even by rebooting.

I wanted to upload a log but the use of this forum is just cruel. sorry.

Edit:
Thanks Merlin for the help.
After so many years, i think I am just annoyed and frustrated with Asus because simply said, the customer receives so much less compared to other companies. The Bang for buck Value is just really bad with Asus now.
I'm completely migrating to Firewalla Purple and Omada in January 2022

Nevertheless, you do a great job, without you Asus would be just RIP.

 

[dave14305]

I use Asuswrt-Merlin 386.4 since release and today I noticed a sudden internet failure.


"Internet status: Not connected" is displayed since then and it cannot be fixed even by rebooting.

If you read the first post, you should keep going and read the second post.

 

[kernol]

For some odd reason DNSSEC only gets enabled in Stubby if it's set to "2", while it should looking for "1" rather. Not sure why, I'd have to investigate in past commits if this could be old leftover.

Not sure if my journey to 386.4 will help - but you may recall I had issues with beta2 [mostly Aimesh node] even after reset at that firmware - so reverted to Asus Stock 386-45934, did full factory reset and rebuilt from scratch. I noticed for first time that Stock now included DoT - cloned / adapted? from your Merlinware - so enabled it ... but did not run DNSSEC tests [assumed it worked as before with Enable DNSSEC set to No].

I then dirty flashed to beta3 on both AiMesh Router and Node [from Stock] - again did not run DNSSEC tests.
Dirty flashed to 386.4 and ran tests on everything I could find - including DNSSEC when I picked up the anomaly described in earlier posts on the issue in this thread.

MANY thanks again for your dedication to this project - we'd all be lost without your efforts.

 

[CaptnDanLKW]

Updated yesterday, no issues. The one difference observed (from syslog) but no impact (to me) is multiple entries for this...

Jan 5 13:06:37 RTAC86U dnsmasq[1206]: possible DNS-rebind attack detected: dns.msftncsi.com

This was noted by others somewhere in the thread, with various levels of impact. If my WAN status starts to get wonky, I'll disable the rebind setting.

Just prior to upgrading I decided to enable IPv6 to see if my small ISP finally enabled, not expecting anything, but to my surprise they finished the rollout!

Post 386.4 upgrade, IPv6 still working fine.

2.4Ghz stable for my IoT devices (no TP Link devices)

Connect time is the best indicator of stability and at > 24hours, I expect no issues.

I'm tempted to try to enable GN1 and see if they fixed those issues. I'd like my fringe devices connect to the node they are MUCH closer to, but even in the low -70s they are stable so I'm still weighing the risk/reward. I have not seen anyone comment on moving back to GN1 yet.

Good release for me.

 

[SheikhSheikha]

Hi SheikhSheikha,

First of all, thanks for your reply. I clean all of the cookies, histories and caches still cannot have a different result. Thx

Flash again without any usb drives (if any). If that does not work: find the reset guidance (nuclear reset) from user L&LD on this forum and follow his directions on how to configure your router. https://www.snbforums.com/members/l-ld.24423/#about

 

[WMConey]

Wifi code comes directly as 100% binary files from Asus. There is nothing for me to test or investigate there, wifi is what it is. Start reviewing your wifi configuration first. The fact that most client issues are on the 2.4 GHz lead me to believe that most of you are keeping advanced features enabled such as Implicit Beamforming or Airtime Fairness, which has well documented problems with a lot of cheap IoT wifi SoCs. Disable these features on the 2.4 GHz band, none of your clients can make use of them anyway. Sometimes, a complete power cycle (not just a reboot) of the router and the clients has also been known to help, as it ensures both are trying to establish a fresh connection.

Just to confirm, I used to have problems with many of my iOT devices on 2.4G. Finally one day I went in and changed that band to "lowest common denominator" - no beamforming, no Airtime fairness, only MCS 7, etc, etc - and I haven't had issues with devices dropping offline since.

 

[mromero]

Wifi code comes directly as 100% binary files from Asus. There is nothing for me to test or investigate there, wifi is what it is. Start reviewing your wifi configuration first. The fact that most client issues are on the 2.4 GHz lead me to believe that most of you are keeping advanced features enabled such as Implicit Beamforming or Airtime Fairness, which has well documented problems with a lot of cheap IoT wifi SoCs. Disable these features on the 2.4 GHz band, none of your clients can make use of them anyway. Sometimes, a complete power cycle (not just a reboot) of the router and the clients has also been known to help, as it ensures both are trying to establish a fresh connection.

For the record, my Roomba is connected to my 2.4 GHz band, and despite being at the complete other end of the apartment and being parked right next to my microwave oven (which is why connection time typically gets reset about every 24 hours), it was showing 31 hours of connection time when I checked earlier tonight before flashing a new firmware build. (which means the connection even survived me microwaving my pizza 6 hours ago). My Goovee light that I turn on at night have also no problem connecting to the 2.4 GHz band. As for the 5 GHz band, both my tablet and my phone both showed over 130 hours of connection time.

Regarding the WAN Disconnection State: please, read post #2. So far, the vast majority of issues turned out to be self-inflicted wounds from people who had cleared the value, or replaced it with an incorrect value (www.google.com is NOT a good test, as the IP address will change depending on which DNS servers you are querying). Restoring the WAN monitoring to proper values will fix it.

Your latest firmware is rock-solid on 2.4 GHz and 5 GHz on the AC86U with about 14 clients humming along nicely in the neo-tropics. Keep up the great work!

 

[bbunge]

Not sure if my journey to 386.4 will help - but you may recall I had issues with beta2 [mostly Aimesh node] even after reset at that firmware - so reverted to Asus Stock 386-45934, did full factory reset and rebuilt from scratch. I noticed for first time that Stock now included DoT - cloned / adapted? from your Merlinware - so enabled it ... but did not run DNSSEC tests [assumed it worked as before with Enable DNSSEC set to No].

I then dirty flashed to beta3 on both AiMesh Router and Node [from Stock] - again did not run DNSSEC tests.
Dirty flashed to 386.4 and ran tests on everything I could find - including DNSSEC when I picked up the anomaly described in earlier posts on the issue in this thread.

MANY thanks again for your dedication to this project - we'd all be lost without your efforts.

Asus version of the firmware with DoT does not include DNSSEC. I have run the Asus 386.45934 up to the release of Merlin 386.4 beta 2. I have tried several ways to add the code to enable DNSSEC in Stubby with the Asus firmware and have failed. The Merlin 386.4 also has a newer version of Stubby.
As I have stated before, the online tests do not prove that the local version of DNSSEC works.

 

[RMerlin]

Sacrilege!

Leftovers from Sunday night. Pepperoni and bacon, with stuffed crust. For a frozen pizza, this Mike's is damn good.

 

[RMerlin]

nd since I had connection problems with all their newer firmwares, that was why I switched to Merlin firmware, but now it happens again.......

SInce the wifi driver is closed source, performance/stability of Wifi will always be identical to that of the corresponding stock firmware version.

 

[RMerlin]

Jan 5 13:06:37 RTAC86U dnsmasq[1206]: possible DNS-rebind attack detected: dns.msftncsi.com

This was noted by others somewhere in the thread, with various levels of impact. If my WAN status starts to get wonky, I'll disable the rebind setting.

Make sure custom scripts are enabled, then create /etc/configs/dnsmasq.conf.add with the following content:

rebind-domain-ok=dns.msftncsi.com

 

[torstein]

Oh my, already 24 pages long thread. Too much to read through.

So, what's the verdict? Is it safe to update from 386.3_2, or have critical bugs been discovered now that it's released to the public? (Nothing too fancy here, OpenVPN server, OpenVPN client (mullvad) and NextDNS cli installed)

 

[shabbs]

Just to confirm, I used to have problems with many of my iOT devices on 2.4G. Finally one day I went in and changed that band to "lowest common denominator" - no beamforming, no Airtime fairness, only MCS 7, etc, etc - and I haven't had issues with devices dropping offline since.

I went through my 2.4GHz WIFI settings today and adjusted a few additional ones. Will let those settle in for 24hr and confirm things are still good and then re-attempt the 386.4 roll forward.

 

[tsanga]

FWIW -

My own experience with 386.4 on RT-AC1750 B1 (same as RT-AC66U B1) using the AC68U FW has been rock solid with a mix of g, n and ac clients on both bands. It’s an AiMesh router with a AiMesh node (RT-AC66U B1) running stock FW.

I manually pick my channels with 20 Hz and 80 Hz widths in 2.4/5.0 GHz bands, with Universal/Implicit Beamforming and Airtime Fairness on defaults (ON and OFF respectively).

Even the smart wifi switch in the backyard which in the past is finicky with dropping 2.4 GHz connections is showing 73% signal strength (all time high) with as much uptime as the router.

 

[ColDen]

Leftovers from Sunday night. Pepperoni and bacon, with stuffed crust. For a frozen pizza, this Mike's is damn good.

Sound like the Superstar most likely purchased at Costco Éric

 

[Noel K.]

"The Internet Service Provider's DHCP service is not working properly" a constant error when updating to 386.4, restarting the device does not help. When returning to 386.3.2, everything works like an atomic clock, there are no errors. Authorization of the IPoE provider's e at the MAC address. Maybe someone has encountered help.

It is the same for me :-(

 

[dentar]

I have a fairly big list of authorized keys for ssh access.
Sadly, the input-length of the 'administration > system > authorized keys' is limited so that i have to edit the file in
/tmp/home/root/.ssh/authorized_keys
with vi to add the missing entries.

Any chance to get that fixed (increase the input length in the webgui)?

 

[dave14305]

I have a fairly big list of authorized keys for ssh access.
Sadly, the input-length of the 'administration > system > authorized keys' is limited so that i have to edit the file in
/tmp/home/root/.ssh/authorized_keys
with vi to add the missing entries.

Any chance to get that fixed (increase the input length in the webgui)?

It’s really off-topic for this thread, since it wasn’t a part of this new version.

Consider switching to ed25519 keys which are much shorter in length. 2999 chars is the max for the nvram field.

 

[PretorianADB]

SInce the wifi driver is closed source, performance/stability of Wifi will always be identical to that of the corresponding stock firmware version.

I have many iot device (30 Shelly) connected to 2.4ghz, I have no problems with 386.3_2 on my 2 RT-AC88U. I’ve dirty flashed to the last Merlin and the 2.4ghz clients start to random disconnections, or unable to connect to Wi-Fi, downgrade my routers to 386.3_2 and everything works fine….

 

[nzwayne]

I went through my 2.4GHz WIFI settings today and adjusted a few additional ones. Will let those settle in for 24hr and confirm things are still good and then re-attempt the 386.4 roll forward.

Something happened in the 2.4Ghz from Beta3 to Release code. My two problem 2.4GHz devices, EPSON 837 printer & LaCrosse Projection clock, I had to reset and re-establish again to the RT-AX88U AiMesh setup. Not had this occur on any of the prior Alpha or Beta dirty (filthy..) updates.
I use these settings for 2.4GHz...

• Set “Protected Management Frames” to “Capable”
• Set 2.4GHz Channel Bandwidth to “20MHz”. Control Channel = Auto
• On 2.4GHz set “Bluetooth Coexistence” to “Enable”
• Preamble Time (on 2.4 GHz only) = Short (older devices will require ‘Long’)
• Disable settings Airtime Fairness & Universal Beamforming

A couple of times over last 2 years to sort WiFi things out, I use a different SSID on the RT-AX88U for some hours, then went back to the SSID I really want active. A tip I believe from @L&LD.