What's new

Release Asuswrt-Merlin 386.4 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.
Dirty flash to AC68U is now telling me NVRAM is low. I have only 14 DHCP reservations and "nvram show" doesn't show anything huge. Is there something else I should look at? Must I factory reset and will reset really fix this? Or is my 68U getting too old and I need a unit with more NVRAM?
 

Attachments

  • nvramlow.png
    nvramlow.png
    8.6 KB · Views: 158
  • usage.png
    usage.png
    2.7 KB · Views: 156
I am using this fork only so don't know but I have seen this https://itigic.com/we-tested-wireguard-vpn-on-asus/ and others talking about wireguard, may be I am mistaken.
Note the very last sentence in that article you linked too...
As you have seen, we have a large number of improvements to come, right now all these functions are in beta phase, so they could have bugs, but in our tests with WireGuard Server everything has worked perfectly.
Right now the Wireguard functions they are talking about in that article are in beta phase in the Asus firmware.
 
Thanks, for now I've written a log tailer to restart dnsmasq when it sees the tainted line to tide things over until I have time to go through a factory reset. Or until I find a way to convince my wife it means I /have/ to buy an AX86U...
I've mentioned this behavior already in the beta 1 : http://www.snbforums.com/threads/386-4-alpha-build-s-testing-available-build-s.74186/post-726257
Fun fact: i already used your great script scMerlin there to restart DNS/DHCP Server (dnsmasq) and fly :) Sidenote I tried to install ( for Fun) Plex on the router and ran in some more of these Tainted hiccups. After a clean install with this final build the Tainted hiccups are still there. I just go over to your script and click :) It doesn't border me that much, as i don't think its critical. But i can be wrong cause I'm not that technical. You both create great user friendly software!
 
386.4 problematic for me on my RT-AC5300, reverted back to 386_3_2
I use 5 Asus EA-AC87 Media Bridges for my various security cameras at my premises.
Lost all connectivity to these bridges for some reason, after reverting all working again.
 
I don't have load/temp issues on my test AC86U, but I'm getting similar 5GHz Wi-Fi disconnections like in beta 2 here. I left wirelessly connected laptop playing Amazon TV show for few hours and it re-connected like 5-6 times. This router was running Asuswrt 45956 for my IPv6 tests and Wi-Fi was stable to the same client. I don't know if firmware Wi-Fi drivers are different in Asuswrt.

Anyone else with AC86U and 5GHz Wi-Fi intermittent issues? Could be the client's Realtek RTL8822CE specific, not sure.
Seem to be having a similar issue with a Nest Cam indoor (original wired model). Regular disconnects on this device only (and actually on both wifi bands) for the AX56U. Was not an issue previously (I did not run the beta builds).
 
Installed today to my AC86U, works great so far. "Nuked" after flash.

Screenshot 2022-01-03 at 22-21-59 ASUS Wireless Router RT-AC86U - System Information.png
 
Thanks, for now I've written a log tailer to restart dnsmasq when it sees the tainted line to tide things over until I have time to go through a factory reset. Or until I find a way to convince my wife it means I /have/ to buy an AX86U...
The correct number of bleeding edge routers in a household = n+1.
 
I have been having problems with some smart bulbs not being able to hold a steady connection on my 2.4gz radio after upgrading a AX88U router to merlin 386.4 or even factory 3.0.0.4.386.45934. However, after restoring 386.3, everything works fine. Does anyone know what changed in firmware update for the 2.4 GHZ WIFI radio?

Background:

I have 4 TP-LINK LB110 smart bulbs, one KL120, and a HS105 smart plug which have worked flawlessly up until 386.4. However, after upgrading from 386.3 to 386.4, all smart bulbs disconnect several times an hour with “wl0.1: STA MAC IEEE 802.11: disassociated“ and “wl0.1: MAC RADIUS: starting accounting session BCE13EF2E594CE5C” – “wl0.1: MAC WPA: pairwise key” in the system log. As a result, the smart bulbs frequently time out when trying to manage through the KASA app.

I have tried the following troubleshooting steps with no success other than reverting to 386.3 where everything works stable.

1) Problem starting after upgrading router from 386.3 to 386.4 Beta 3 (dirty upgrade, not a full reset). Tried following steps no success:
  • Hard resetting bulbs to factory defaults and rejoining guest network.
  • Uninstalled several plugins including Skynet, Diversion, YAZI (bulbs were in isolated Guest network).
  • Disabled WIFI 6 on 2.4 GHZ radio, changed channel (thought maybe too many conflicts), reduced channel bandwidth to 20 MHZ, ensure WIFI security still WPA 2 for guest, disabled protected frame management, disabled universal beam forming.
  • Tried lowering RTS threshold.
2) Upgraded 386.4 BETA 3 to 384.4 final and problems persisted.
3) Did a hard reset on router and re-uploaded 386.4 firmware and still no luck.
4) Did hard rest on router again and did a clean upload of ASUA factory 3.0.0.4.386.45934 and problems persisted.
5) Hard rest router with clean install of Merlin 386.3 and problems went away.
6) The issues returned as soon as I upgraded to 386.4 again.
7) Did dirty downgrade back to 386.3 and all the problems went away. Bulbs are rock solid.

Given the only WIFI clients that seem to be experiencing issues with 386.4 are the bulbs, I was leaning towards an issue with the bulbs that did not get exposed until the latest firmware update. Note I also have two TP-LINK HS200 switches that did not experience any problems (I’m guessing they use different wireless chips). However, it seems like this is a problem isolated between those bulbs and the AX88U as I installed all the same bulbs at my mother’s house, and she has no problem running factory firmware 3.0.0.4.386.45934. I would like to see if TPLINK would be willing to do anything, but I suspect they will point their finger back at the router.

Any insights would be helpful. It seems there has to be something in the new ASUS GPL causing this issue. The GPL associated with Merlin 386.3 is stable and no wifi disconnect issues are being experienced with my smart bulbs. I hate not being able to update to the latest release... hopefully I'm not missing out on a bunch of vulnerability patches.
 
386.4 problematic for me on my RT-AC5300, reverted back to 386_3_2
I use 5 Asus EA-AC87 Media Bridges for my various security cameras at my premises.
Lost all connectivity to these bridges for some reason, after reverting all working again.


I had a similar problem with my smart bulbs.... are your bridges connecting on the 2.4ghz band? If so, check out the system log and see if they are continually connecting and reconnecting.

For me, the problem resides in both 386.4 as well as ASUS's latest factory GPL. Seems like there may be a bug in the GPL.
 
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 this release;
  • Merges with GPL 386_45958.
  • Adds support for the RT-AX86S (uses the same firmware as the RT-AX86U).
  • HND firmware now include both the kernel module and userspace tool for Wireguard. There is no built-in support for Wireguard at this time, these are only included for end-user or third party usage. Asus is still working on their own implementation, which isn't available yet.
  • OpenVPN server now supports IPv6, both for incoming connections, and for routing access to the LAN clients over IPv6. Note however that redirecting IPv6 Internet traffic through your server is not supported.
  • Component updates: curl 7.79.1, vsftpd to 3.0.5, openssl to 1.1.1m, wget to 1.21.1, nettle to 3.7.3, dnsmasq 2.86, openvpn 2.5.5, tor 0.4.5.11, miniupnpd 2.2.3-git 20211017, inadyn 2.9.1 and amtm 3.2.2.
  • jitterentropy-rngd was replaced by haveged. Haveged is more resource-intensive, but it works properly under older 2.6.x kernels.
  • dnsmasq was reverted back to using nettle for its DNSSEC crypto handling (since openssl support never got mainlined and was increasingly problematic to support)
  • miniupnpd now uses the real public IP address instead of any potentially (double-)NATed address for the WAN.
  • Reworked DHCP hostname support to use Asus's own implementation.
  • A couple of various bugfixes

Please review the Changelog for complete details.

Notes:
  • 386.4 uses the new DHCP hostname implementation from Asus (your entries will automatically be converted to the new format on first boot). This means however that reverting to a previous firmware version will lose all of your defined static lease hostnames, so backup your configuration before upgrading if you expect you might need to downgrade afterward.
Please keep posts in this thread on this specific release. This thread will be locked after a few weeks once the release feedback has died down.

Downloads are here.
Changelog is here.
RT-AX88U upon upgrade from 386.3 to 386.4 was unable to connect to the Internet. Router showed red (Internet) indicator light. Decided to reset router and reconfigure. After reset doing OK on 386.4. I am assuming that a development change was incompatible with an existing setting. Other users have reported DHCP issues- and I was pointing to my own Raspberry Pi device for DNScrypt, DNS and Pihole services.

I did not back-up my settings before upgrade- but even if I did, the same issue would likely occur upon restore.
 
Thanks, for now I've written a log tailer to restart dnsmasq when it sees the tainted line to tide things over until I have time to go through a factory reset. Or until I find a way to convince my wife it means I /have/ to buy an AX86U...
Can you please post a tutorial on how to convince them?...
@L&LD ? A nuclear one?
 
Dirty flash to AC68U is now telling me NVRAM is low. I have only 14 DHCP reservations and "nvram show" doesn't show anything huge. Is there something else I should look at? Must I factory reset and will reset really fix this? Or is my 68U getting too old and I need a unit with more NVRAM?
I have 6k NVRAM free - no DHCP reservations but a bunch of custom settings in FlexQoS... Try reset and manually reentering everything and see how much you have free - there is a good chance it will be ok for now...
 
Dirty flash to AC68U is now telling me NVRAM is low. I have only 14 DHCP reservations and "nvram show" doesn't show anything huge. Is there something else I should look at? Must I factory reset and will reset really fix this?
You can create this script and run it first (as posted by RMerlin). It can help (depending on history etc)

I would reset and start fresh. My test AC68U router has ~10K NVRAM left with fresh 386.4 firmware.
I will fully reset / revert to starting from scratch, when the 386.5 firmware series starts, but on my RT-AC68U running on 386.4 after a dirty upgrades from each of the 386 betas, FWIW the NVRAM usage is still fine at 56068 / 65536 bytes. Very similar to Tech9's post above
 
Last edited:
I've mentioned this behavior already in the beta 1 : http://www.snbforums.com/threads/386-4-alpha-build-s-testing-available-build-s.74186/post-726257
Fun fact: i already used your great script scMerlin there to restart DNS/DHCP Server (dnsmasq) and fly :) Sidenote I tried to install ( for Fun) Plex on the router and ran in some more of these Tainted hiccups. After a clean install with this final build the Tainted hiccups are still there. I just go over to your script and click :) It doesn't border me that much, as i don't think its critical. But i can be wrong cause I'm not that technical. You both create great user friendly software!
perhaps i should bundle my little script as an extra watchdog alongside the NTP watchdog in scMerlin
 
Thanks to those who replied to my question on low NVRAM. I bit the bullet and did a full reset and hand-entered all the parameters. Including correcting typos, that took me almost 2 hours, but I have to admit this is the first reset I've done in years, so it was time.

Now I have almost 10k more NVRAM than before, so it was worth it.
 
I had a similar problem with my smart bulbs.... are your bridges connecting on the 2.4ghz band? If so, check out the system log and see if they are continually connecting and reconnecting.

For me, the problem resides in both 386.4 as well as ASUS's latest factory GPL. Seems like there may be a bug in the GPL.
No, all bridges are on 5GHz
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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