Release Asuswrt-Merlin 386.4 is now available

[psychbiz]

Try it with port if you haven't already.

https://routerip:8443/ or https://router.asus.com:8443/

Oddly, I had tried this already several times before posting, including restarting router from power off, but after a couple of hours delay, tried again and it just worked! I hadn't accidentally disabled web access at all. Thank you for your help.

 

[fox244243904]

Hi everyone

Happy new year

I updated to 386.4 with no problems. Many entware packages and chrooted debian for my plex server works very well. My nextcloud also have some trouble with missing GD library. Waiting for a entware repo update.

Now I got some frustrating error every 30mins caused by dcd in top mit PID 23970.
Anyone has the same error? what should I do?

Greetings and sorry for my english..

View attachment 38233

It is caused by the Trend Micro. Possibly a corrupt configuration /tmp/bwdpi/dcd.conf

 

[jak]

Dirty install on AX86U. After 1 day off struceling with 2.4 Ghz connections on 2 devices, reverted back to 386.3.2. Installing 386.3.2 solved the problem. There must be something wrong with the wifi drivers?

 

[learning_curve]

BTW, seems that this tip from the linked thread (and YazDHCP)

Asus RT-AC68U 386.2_6 low on free nvram

I upgraded my RT-AC68U from 384.19 to 386.2_6 but i'm getting the following warning. Your router is running low on free NVRAM, which might affect its stability. Review long parameter lists (like DHCP reservations), or consider doing a factory default reset and reconfiguring. Any idea how I can...

www.snbforums.com

won't work atm with fw 386.4, because Asus has changed NVRAM format? Or at least this is what I gathered from the message posted by Jack Yaz:

YazDHCP - YazDHCP - feature expansion of DHCP assignments (increasing limit on the number of DHCP reservations)

AC86U on MerlinWRT 386.3_2 This is what I am getting on install Enter answer (y/n): y YazDHCP: DHCP hostnames not exported from nvram, no data found When I manually try to run it I get Choose an option: 1 tail: can't open '/jffs/addons/YazDHCP.d/DHCP_clients': No such file or...

www.snbforums.com

I've run YazDHCP for a long time now. It always has and still is, running perfectly for me (throughout all of the upgrades etc I've never has any issues with it, ever!) So another thanks to @Jack Yaz

Not a biggie, but FWIW the RMerlin script mentioned, DID work perfectly / without any issues / no collateral damage etc (for me) on FW 386.4. Other users may not share the same setup/good luck?

Unlike many users in this specific thread, I've had practically zero trouble to date with the FW 386.4 upgrade, apart from two small items, both of which, I've covered in one of my previous posts, i.e.

The small bug posted (and fixed) here by RMerlin:

Release - Asuswrt-Merlin 386.4 is now available

After a long wait, the new version of Asuswrt-Merlin is now available. 386.4 merges with GPL 386_45958 (plus a number of security fixes backported from newer code), updates various components, and also adds support for the RT-AX86S (uses the same firmware as the RT-AX86U). The highlights of...

www.snbforums.com

Plus, the removal of IPv6 DDNS (which has just recently been posted about again, by JackYaz: http://www.snbforums.com/threads/asuswrt-merlin-386-4-is-now-available.76498/post-734071

Many potential faults / issues / queries have been posted far, but most seem to relate to individual's set-ups (thus a few knock-on individual effects...) as opposed to any major FW 386.4 failures?

 

[expor]

After one day runtime 5ghz became unusable. All devices keep getting dropped and when connected the speed is horrible. Reported connection speed is 800+ but speedtests are stuck at around 250kbs. Will probably have to revert to older FW until this is fixed. Other devices now show the same behavior as what I had seen on my phone for more than a week already. Hard to connect to 5ghz and getting dropped constantly with horrible speed if the connection persists.

Router log shows nothing that seems off, just that all devices are dis/reconnected several times.

 

[Diamond67]

I've run YazDHCP for a long time now. It always has and still is, running perfectly for me (throughout all of the upgrades etc I've never has any issues with it, ever!)

With my AC68U I am very close to running low on free NVRAM.

So I decided to try and install YazDHCP just to test if it would free some amount of used NVRAM.

But unfortunately it seems that a fresh install of YazDHCP on 386.4 will cause some issues while exporting existing Manually assigned IP entries.

Maybe I'll try the RMerlin script later. Or wait for the update for YazDHCP. No biggie anyway.

 

[learning_curve]

Thanks for your reminder, I think beta 2 may be the last version to support IPv6 DDNS. Okay, if I need this feature, I might go back to beta 2. By the way, do you have any suggestions about using a script to manually register IPv6 to Asus DDNS? Is it possible? Because I think I don't have a token.

Yes, the FW 386.4 Beta 2 was the last time that things related to IPv6 DDNS worked (of a fashion). It seems that everyone; All IPv6 users / IPv6 DDNS users / RMerlin / You / Me / A.N.Other etc will need to wait, until Asus move their own 386.5 Betas to Official Releases and then... we can all see what's been fixed / wait for the Asuswrt-Merlin 386.5 FW release(s) & then try again....

I have posted before, that I am using No-IP DDNS (as they do support IPv6 DDNS) as well as Asus DDNS and with the official Asuswrt-Merlin 386.4 FW release (i.e. I'm not using any previous Beta), I can quite easily & successfully, nslookup both the IPv4 Asus DDNS and IPv4 No-IP DDNS and... the IPv6 No-IP DDNS too (via nslookup -query=AAAA $hostname). The No-IP IPv6 DDNS is NOT being updated from the router, which is correct, as you've read in several other posts (removal of IPv6 DDNS functionality after Beta2 etc). In the interim, IF it changes, you must manually update the IPv6 / AAAA address on the NO-IP website yourself... until... maybe... the 386.5 'fixes' arrive for the acknowledged IPv6 DDNS issues. However, it's still a valid IPv6 DDNS address & it works. It's nowhere near perfect / as it should be / as you want it to be @Yota but, it might be worth a look for you in the interim, instead of going back to the Beta2 release, until the 386.5 'fixes' finally arrive?

 

[kernol]

RT-AX86U rock steady on 386.4 - many thanks to @RMerlin and the alpha/beta testers.

I have noted the Change Log info regarding DNSSEC - but no advisory about having to turn "Enable DNSSEC support" to Yes - instead of No as it was in previous firmware releases.

I can't get consistent results without the above change to YES from any of these test sites ...
https://rootcanary.org/test.html
http://dnssec.vs.uni-due.de/
http://0skar.cz/dns/en/
http://en.conn.internet.nl/connection/

Anyone else found the same need to change. It doesn't matter whether I use Cloudflare of Quad9 - fails DNSSEC test if set to No as before.

 

[shabbs]

Same behaviour for one of my indoor Nest Cams (2.4 Ghz). Didn't seem to impact the newer IQ camera on same band.

This was a problem even after a full reset/reconfigure.

Reverted to previous firmware and all back working.

That's not encouraging. Mine are all the "older" 1080p HD Outdoor Cams, not the IQ ones.

 

[EdoAsus]

Hi everyone

Happy new year

I updated to 386.4 with no problems. Many entware packages and chrooted debian for my plex server works very well. My nextcloud also have some trouble with missing GD library. Waiting for a entware repo update.

Now I got some frustrating error every 30mins caused by dcd in top mit PID 23970.
Anyone has the same error? what should I do?

Greetings and sorry for my english..

View attachment 38233

Seems a common issue for many users on this release, it's a TrendMicro deamon that crashes, I guess TrendMicro or Asus has to fix it.

 

[sharmay]

If your router supports Wireguard, you can install the "Wireguard Session Manager" from the AMTM utility. There is a large thread on the use of the session manager in the Add-Ons forum.

Will give it a try, thank you

 

[brself2]

That's not encouraging. Mine are all the "older" 1080p HD Outdoor Cams, not the IQ ones.

That's not encouraging. Mine are all the "older" 1080p HD Outdoor Cams, not the IQ ones.

Something is not right with 386.4 for certain devices on the 2.4ghz. Two of my TP-Link devices are not working properly. I also have two 1080p outdoor Nest cameras but are working perfectly fine on 5ghz. I have two AX88U, main and node, both running 386.4. Other than the two devices not working properly, everything else is fine. I just took those devices off line and replaced them.

 

[SheikhSheikha]

Updated from Beta to 386.4 by flashing 3 times. (I normally flash 2x but my iOT stuff did not all connect on the 2.4 immediately) After the 3th flash routers are running for a few days and everything works fine! Great work Erik and all others involved.

 

[iTyPsIDg]

I did a dirty upgrade from 386.3_2 to 386.4. It went smoothly; however, there were behind-the-scenes issues that I didn't notice until streaming later.

• YazFi lost its configuration.
  • It is possible this had happened previously because I don't check it that often.
• My LAN wasn't using the VPN. Its configuration in VPN Director disappeared.

Once I corrected those issues, everything seemed to run just fine. It's been a little less than 24 hours so far.

 

[bbunge]

RT-AX86U rock steady on 386.4 - many thanks to @RMerlin and the alpha/beta testers.

I have noted the Change Log info regarding DNSSEC - but no advisory about having to turn "Enable DNSSEC support" to Yes - instead of No as it was in previous firmware releases.

View attachment 38235

I can't get consistent results without the above change to YES from any of these test sites ...
https://rootcanary.org/test.html
http://dnssec.vs.uni-due.de/
http://0skar.cz/dns/en/
http://en.conn.internet.nl/connection/

Anyone else found the same need to change. It doesn't matter whether I use Cloudflare of Quad9 - fails DNSSEC test if set to No as before.

Always had to be set to Yes to enable DNSSEC via dnsmasq.
I enable DNSSEC in Stubby using a stubby post config file. I ran all the test links you provided with positive results.

 

[shabbs]

Something is not right with 386.4 for certain devices on the 2.4ghz. Two of my TP-Link devices are not working properly. I also have two 1080p outdoor Nest cameras but are working perfectly fine on 5ghz. I have two AX88U, main and node, both running 386.4. Other than the two devices not working properly, everything else is fine. I just took those devices off line and replaced them.

This may be in the wireless driver area that Asus controls and Merlin has no access to, which is not good for us. I may try the latest stock firmware on one of my APs that has a number of Nest cams to confirm if this is also an issue there. Replacing all my Nest HD cams is not something I'm interesting in taking up just yet.. and it would be a very pricey course change.

Up here in Canada, Outdoor Nest Cams are restricted to the 2.4GHz spectrum due to regulations so I can't even try to pop them on to my 5GHz bands.

 

[joegreat]

I updated to 386.4 with no problems. Many entware packages and chrooted debian for my plex server works very well. My nextcloud also have some trouble with missing GD library. Waiting for a entware repo update.

Now I got some frustrating error every 30mins caused by dcd in top mit PID 23970.
Anyone has the same error? what should I do?

View attachment 38233

Was already discussed here (and postings further down) - most likely pixel server is crashing Trend Micro - you need do disable one of them...

 

[XIII]

Not sure if this is a 386.4 issue (that's why I started a separate topic for it before), but it might be... (dnsmasq 2.86 issue?)

Entries added in /jffs/configs/dnsmasq.conf.add are not added to the hosts file.

How to change NextDNS rewrite into dnsmasq address entry?

I'm trying to change my NextDNS rewrite (router.mydomain.com to 192.168.1.1) into a dnsmasq entry (which I believe makes more sense, since it will work locally only anyway). This is what I added in /jffs/configs/dnsmasq.conf.add: address=/router.mydomain.com/192.168.1.1 This is what I added in...

www.snbforums.com

 

[kernol]

Always had to be set to Yes to enable DNSSEC via dnsmasq.
I enable DNSSEC in Stubby using a stubby post config file. I ran all the test links you provided with positive results.

Could it be that DNSSEC was enabled in Stubby within the prior version of the firmware itself - but is not so enabled in the latest firmware on the RT-AX86U?

What is especially curious is that I upgraded the office RT-AC86U from prior Merlin version and it works with Enable DNSSEC support in the NO position ]for all 4 tests] ??? Could the Stubby setting have carried over from prior firmware?

 

[ColinTaylor]

Not sure if this is a 386.4 issue (that's why I started a separate topic for it before), but it might be... (dnsmasq 2.86 issue?)

Entries added in /jffs/configs/dnsmasq.conf.add are not added to the hosts file.

How to change NextDNS rewrite into dnsmasq address entry?

I'm trying to change my NextDNS rewrite (router.mydomain.com to 192.168.1.1) into a dnsmasq entry (which I believe makes more sense, since it will work locally only anyway). This is what I added in /jffs/configs/dnsmasq.conf.add: address=/router.mydomain.com/192.168.1.1 This is what I added in...

www.snbforums.com

This is normal behaviour. Nothing has changed.