Release Asuswrt-Merlin 386.12_6 is now available for AC models

[heywire]

Same situation here, i'm currently stable with 386.12, all the new builds create problems on wifi and i notice that the problems continue to be reported. Unfortunately Merlin's hands are tied and he can't do more than this, for now i'll stay on .12 and let AdGuardHome manage the DNSSEC.

So you're stable with 386.12, but not the sub-releases (.12.2, 12.4, 12.6)?

How does your history with the recent firmwares look; were you rock stable over a significant period of time at any point going backwards with 386.11, .10, .9?

I'm saying "for a significant period of time" because as I mentioned, I have experienced rare (approx 1-3 weeks between) crashes with at least .11, even if it was seemingly stable from day to day until that.

I'm now back on .10 crossing my fingers that I can land on a long term stable version to fall back on. Going forward, at the slightest hint of trouble with newer versions, I'm going to revert to it (I hope to find a newer 100% stable release with the next landmark GPL release tho, as the .10 is almost a year old)

(seriously considering putting the whole setup behind an OPNsense/pfSense box at this point, if that means I can relegate the Asus Aimesh setup to taking care of the wifi mesh network on a older, stable fw, while the Box takes care of internet access, CakeQOS and security. So sick and tired of Asus' lack of QC with new Firmware versions; it's a gamble every time, and I find myself loosing a lot lately).

 

[RMerlin]

There is no way this releases introduced "new" wifi issues. Literally nothing else than dnsmasq was changed.

merlin@ubuntu-dev:~/amng$ git log 386.12_4..386.12_6 --oneline
36742c8dbb (tag: 386.12_6, origin/386.12_x, 386.12_x) Fix typo in changelog
4735427f0e Bumped revision to 386.12_6
61324445c3 Updated documentation
b23b44cc49 dnsmasq: Fix error introduced in 51471cafa5a4fa44d6fe490885d9910bd72a5907
5eb2eb5074 Fix spurious "resource limit exceeded" messages.
7b3720fa4d dnsmasq: update to 2.90

 

[Tomo]

My story is quite simple, i've never had a system reboot, never had strange wifi disconnections, so when from 386.12_2 i started having random disconnections of some wifi devices that never caused problems i started testing the various solutions ( system reset with clean configuration, different wifi options) but nothing, this with all versions after 386.12, all. My idea is that to solve the very famous "DCD constantly crashing" Asus has broken something that affects the wifi and if a new GPL doesn't come out we won't have a solution, but for me it's not a problem, never used Ai Protect and for the DNSEC i use AdGuardHome, on the other hand the HW is old we cannot expect infinite support, it is also right to upgrade the hardware if you also look at security.

 

[heywire]

My story is quite simple, i've never had a system reboot, never had strange wifi disconnections, so when from 386.12_2 i started having random disconnections of some wifi devices that never caused problems i started testing the various solutions ( system reset with clean configuration, different wifi options) but nothing, this with all versions after 386.12, all. My idea is that to solve the very famous "DCD constantly crashing" Asus has broken something that affects the wifi and if a new GPL doesn't come out we won't have a solution, but for me it's not a problem, never used Ai Protect and for the DNSEC i use AdGuardHome, on the other hand the HW is old we cannot expect infinite support, it is also right to upgrade the hardware if you also look at security.

There is no way this releases introduced "new" wifi issues. Literally nothing else than dnsmasq was changed.

Most likely intermittent problems that worsen and improve due to the reboots themselves, rather than code differences, then...(?)

Perhaps also the TrendMicro shenanigans threw a monkeywrench or five in along the timeline as well.

I did experience some of this in 386.12 (at least, if not 386.11), that there were some problems that required a reboot which gave some temporary relief. I actually remember having a lot of issues while jugging between 386.11 and 12, a phenomenon which I commented in the 386.12 thread.

Anyways, I think it is safe to conclude that at least these two releases latest (.11 and 12.x) have common problems with stability.

 

[heywire]

My idea is that to solve the very famous "DCD constantly crashing" Asus has broken something that affects the wifi and if a new GPL doesn't come out we won't have a solution

The official FW is quite old as well (Version 3.0.0.4.386_51915 - 2023/07/10).
I'm guessing that fix would have hit the GPL by now.

 

[RMerlin]

Most likely intermittent problems that worsen and improve due to the reboots themselves, rather than code differences, then...(?)

That is my theory. The reboot occuring when one downgrades the firmware would most likely be what actually helped/fixed any issue encountered, not running the previous firmware itself.

When running into odd wifi issues, I frequently recommend doing what I call an electrical reset. By unplugging the power with the power switch still left on, this drains any residual electrical charge, causing the internal chip to fully reset itself, something that might not fully occur with a simple reboot.

 

[heysoundude]

Remember to add which version you are upgrading from (and if it worked 100% stable).

From 12_4 to 12_6, but I didn't unmount my entware drive and may have toasted it...or it was just time for it to expire.
I've a spare m.2 kicking around and will grab an enclosure for it that has usb3.0 (i don't need to worry about 2.4GHz interference). in the meantime, damnit Ads are annoying...lol

I'd like to add, for @RMerlin and whomever else: I've never had an issue with dirty upgrades before as long as I unmounted the entware drive before flashing, but this time something went fubar with DHCP server when I recklessly forgot to unmount beforehand. Because this update was for dnsmasq, and entware recently made a similar upgrade to unbound to address the same CVE threats/issues, I'm actually not particularly surprised I'm having issues with my rig when I broke one of the cardinal rules of upgrading.
so my penance shall be a complete re-do, after a factory reset.
Mea culpa; mea maxima culpa.

UPDATE - very glad I did the factory reset. It's like I bought a brand new router. I'll have to remember to do this at every version bump, not incremental updates. I don't recall 64bit entware versions before...but it's been a while. I also re-did my media bridge to my old n66u, re-enabling the 2.4GHz network and enabling MAC filtering on it so that all of my wireless devices go to 5GHz, and the 2.4 is kept for the bridge....it's snappier than before this way. And yeah, the old seagate survived, so it's been re-formatted and is back in service for entware.

 

[MaliST]

This button dont work

 

[Ripshod]

This button dont work

View attachment 56846

1. Wrong thread
2. You're the only one reporting this so it's likely down to your settings.

When was the last time you performed a factory reset and manual setup on your router?

 

[MaliST]

"When was the last time you performed a factory reset and manual setup on your router?"
today...

 

[Ripshod]

"When was the last time you performed a factory reset and manual setup on your router?"
today...

Reflash the same firmware again, and join the correct thread if you still have a problem.

Release - Asuswrt-Merlin 3004.388.6 is now available

Asuswrt-Merlin 3004.388.6 is now available for all supported Wifi 6 models. This release focuses on merging new GPL code from Asus. 26-Feb-2024: Asuswrt-Merlin 3004.388.6_2 is now available. 3004.388.6_2 (26-Feb-2024) - UPDATED: dnsmasq to 2.90 (resolves CVE 2023-50868 and CVE 2023-50387)...

www.snbforums.com

 

[MaliST]

ok...tnx

 

[Tech9]

Sorry for pushing your buttons, man. Maybe I'm wrong.

Maybe not. @heywire is overly sensitive about RT-AC86U. The high-end GT-AC5300 based on the same hardware with the same radios is already EoL. There is a chance extremally successful RT-AC68U will outlive the first released NHD model with well known hardware and software issues. Time will tell, hope dies last.

There is no way this releases introduced "new" wifi issues.

I don't know details around firmware compilation process, but this same thing happened with one of 386 releases for RT-AX86U. With no Broadcom Wi-Fi drivers change it wasn't working properly and firmware roll back was fixing it instantly. Not all routers were affected, but on my unit it was reproduceable every time issue.

 

[bibikalka]

There is no way this releases introduced "new" wifi issues. Literally nothing else than dnsmasq was changed.

merlin@ubuntu-dev:~/amng$ git log 386.12_4..386.12_6 --oneline
...
7b3720fa4d dnsmasq: update to 2.90

So I had the log for 12_6, and then the log for the downgraded 12_4. I stripped the leading time stamps, and diff'ed the 2. It looks like (a) DHCP is in fact run by dnsmasq (which is what's being updated in this version), and (b) 12_6 does not seem to offer IP addresses as version 12_4 does. I got lucky with my tablet since it did not refresh its DHCP, so I could connect to 12_6 with its prior IP assignment and downgrade to 12_4. So probably 12_6 mis-reads some of the existing DHCP config values somewhere? I presume if one resets those to a clean state, 12_6 may start working.

12_6

grep DHCP n0c.log
dnsmasq-dhcp[1161]: DHCP, IP range 192.168.102.2 -- 192.168.102.254, lease time 1d
dnsmasq-dhcp[1161]: DHCP, IP range 192.168.101.2 -- 192.168.101.254, lease time 1d
dnsmasq-dhcp[1161]: DHCP, IP range 192.168.1.32 -- 192.168.1.254, lease time 1d
dnsmasq-dhcp[1161]: DHCPDISCOVER(br0) 00:08:22:XX:XX:XX
dnsmasq-dhcp[1161]: DHCPOFFER(br0) 192.168.1.222 00:08:22:XX:XX:XX
RT-AC86U-9988 dnsmasq[3214]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset no-auth cryptohash DNSSEC no-ID loop-detect no-inotify no-dumpfile

And here is the working 12_4 output:

grep DHCP n1c.log
dnsmasq-dhcp[1160]: DHCP, IP range 192.168.102.2 -- 192.168.102.254, lease time 1d
dnsmasq-dhcp[1160]: DHCP, IP range 192.168.101.2 -- 192.168.101.254, lease time 1d
dnsmasq-dhcp[1160]: DHCP, IP range 192.168.1.32 -- 192.168.1.254, lease time 1d
dnsmasq-dhcp[1160]: DHCPREQUEST(br0) 192.168.1.249 68:f6:3b:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPACK(br0) 192.168.1.249 68:f6:3b:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPDISCOVER(br0) 192.168.1.12 54:a0:50:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPOFFER(br0) 192.168.1.12 54:a0:50:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPREQUEST(br0) 192.168.1.12 54:a0:50:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPACK(br0) 192.168.1.12 54:a0:50:XX:XX:XX RT-AC68U-FF68
dnsmasq-dhcp[1160]: DHCPDISCOVER(br0) 10:09:f9:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPOFFER(br0) 192.168.1.92 10:09:f9:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPDISCOVER(br0) 5c:41:5a:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPOFFER(br0) 192.168.1.189 5c:41:5a:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPREQUEST(br0) 192.168.1.105 b8:8c:29:XX:XX:XX
dnsmasq-dhcp[1160]: DHCPACK(br0) 192.168.1.105 b8:8c:29:XX:XX:XX net_a1_3F6E
RT-AC86U-9988 dnsmasq[6612]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset no-auth cryptohash DNSSEC no-ID loop-detect no-inotify no-dumpfile

 

[heywire]

Maybe not. @heywire is overly sensitive about RT-AC86U.

I'm trying to correct misinformation, and stop people from wasting their money. You seem dedicated to the opposite because of some bad experienced you have had with it. Thus, I think it's objectively true that the term "oversensitive" applies more accurately to yourself.

 

[KrypteX]

@heywire @Tech9 I think there's some misunderstanding here. I've read @heywire's links above:

ASUS RT- AC86U WIFI DROP OUTS/ SLOW AND FLUCTUATING

I'm following this thread as I'm having intermittent wifi drop-outs on my AC86U. This router is known for multiple common hardware failures including radios. If playing with Wi-Fi settings doesn't improve the situation you may need a new router. Keep it in a cool place, overheating is one of...

www.snbforums.com

Release - Asuswrt-Merlin 386.12 is now available for AC models

Have the latest firmware 386.12_4 for a few weeks now on AC86u. Running AiProtection and TM - have to. There is an AiMesh node connected via 5 Ghz band. About ~20 devices Max at various times. The router is on UPS, so no power supply reboots. The main router is cron rebooted nightly at 4:05 am...

www.snbforums.com

and 100% agree with his stance. I would only name the real cause of what is being conveyed: consumerism.

 

[HarryH3]

Live upgrade on an RT-AC68U from 386.12_4 to 386.12_6 two days ago. It isn't running any non-standard scripts, etc. other than YazDHCP. So far everything is working fine. (Edit to add: This router is a V2 model. I don't know what changes were made between this and the original. Just adding a data point for those that are having wifi issues after upgrading.)

Also upgraded another one that is used as a Media Bridge (though I don't think it even uses dsnmasq in that mode) just to keep them both at the same version.

 

[tun]

Upgrade from RT-AC68U from 386.12_4 to 386.12_6 and now all wifi devices can't connect, except for wired. Not sure what's wrong but rolled back to 386.12_4 and everything fine.

 

[heywire]

Upgrade from RT-AC68U from 386.12_4 to 386.12_6 and now all wifi devices can't connect, except for wired. Not sure what's wrong but rolled back to 386.12_4 and everything fine.

Try doing a manual restart right after the update.

 

[tun]

Try doing a manual restart right after the update.

I did the power off/on after the update, but same issue. Will try again this weekend. Thank you.