Release Asuswrt-Merlin 386.7 is now available for all models

[DiGz_Au]

I wanted to work out why 386.7 was wonky on wifi. Noticed Australia had finally been added to the wifi country list. So I upgraded again and chose Australia and enabled dfs( don't usually do this) can say that for my ax86u now the wifi is similar to last release. What does the country setting change?

 

[Unetwork]

I see quite a few wifi problems with the AX88U on this post.
On my side, I proceeded as follows, as always: Update from 386.5_2 to 386.7 + WPS Reset + JFFS partition formatting + reconfiguration of the parameters manually = no problem to report for more than 8 days on the LAN/WAN/WIFI.
Everything is rock solid.
Even the VPN works perfectly in ON and OFF.
Thanks again to Merlin and the developers.
Enjoy.

 

[mine25]

There is nothing to update, 302 is latest, and was released only a few days ago.

The automated check is done every 48 hours, and updates are not always pushed to all models at the same time.

Thanks @RMerlin for responding. I was on 300 before manually checking for available updates and updating to 302, the screenshot was supposed to show you the actual update settings. This behavior is recurrent on my router, over multiple firmware releases. Also, I see nothing in the logs about automatic update checking, is this event logged?

Here's the log input for the manual update I did:

 

[Akore]

RT-AX86U up and running nicely all day. Speeds normal. Thank you again for your efforts! Connected to a BGW320-500 AT&T fiber set to passthrough mode. Not really sure why the disconnection thing is there in yellow in the screen cap. Working fine.

Also see that a lot on my RT-AC68U. Network Map page show Internet status: Connected but when I go to run the Internet Speed test it has the yellow warning that the function is temp disable. Seems to have started with alpha of 386.7 .... though it seems if I log out and back in it works just fine and no longer has the yellow warning.

 

[Tech9]

What issues?

With all due respect, you seem to ignore more and more user feedback. Beta1 and Beta2 run for 12 days only with mostly success installation reports. The real Beta is your release when people waiting for Stable started upgrading firmware. Quite a few rolled back to the previous release for different reasons. Wi-Fi drivers and AiMesh are closed source, but I can tell you from what I see on AX86U model both work better in Asuswrt after clean installation, reset to factory defaults and manual configuration afterwards. I leave all TrendMicro components disabled and all Wi-Fi settings at Default for cleaner results. No 3rd party user scripts, no USB attached storage. I only lock Wi-Fi channels so Auto channel doesn't bounce around. SmartConnect is Disabled. AiMesh in Asuswrt-Merlin can't find my AC86U no matter what firmware it runs, unless it's wired to the main router. When AC86U is switched to Media Bridge mode, it re-connects every time to AX86U running Asuswrt, but not always when AX86U is running Asuswrt-Merlin. It happens on Asuswrt-Merlin 386.5_2 release as well. I have to reboot AC86U to restore the connection. Exactly the same with AC86U in Repeater mode. Unfortunately, I don't have other Asus router models to test with, but there is definitely something going on around wireless in Asuswrt-Merlin and it's not just Asus GPL related. Performance to clients is identical, but there are some issues with connectivity to other Asus routers. I knew about AiMesh from my previous testing of 386 based Asuswrt-Merlin releases, but now I see Media Bridge and Repeater are also affected. I have noticed it only because of many reboots during testing. Some folks may notice it in months time.

This is not to discourage people from using Asuswrt-Merlin. Your firmware is excellent with all the added features - the best I've seen on home routers. Hard to believe it's a one man project. If you have the time though, look at what may cause the above issues. No one else can solve the puzzle.

 

[JacquesR]

Another AX86U user checking in to report no issues with 386.7, and no perceived difference in performance. I did factory reset a day or so after installation, but that was mostly because I was messing around with Tailscale - everything was working fine before that.

 

[RMerlin]

Also, I see nothing in the logs about automatic update checking, is this event logged?

I don't think it is, however you might get log entries about the AiProtection services restarting when a signature update is installed.

If you have the time though, look at what may cause the above issues.

Everything you posted is about Wifi and AiMesh. What am I supposed to do here? Here is AiMesh, from my point of view as a third party developer rather than an Asus engineer:

merlin@ubuntu-dev:~/amng/release/src/router/amas-utils/prebuild/RT-AX86U$ ls -al
total 188
drwxrwxr-x 1 merlin merlin     84 Jun  5 00:12 .
drwxrwxr-x 1 merlin merlin    272 Apr  6 01:24 ..
-rwxrwxr-x 1 merlin merlin  22532 Jun  5 00:12 amas-utils-cli
-rwxrwxr-x 1 merlin merlin   8537 Jun  4 23:03 amas-utils.h
-rwxrwxr-x 1 merlin merlin 155356 Jun  5 00:12 libamas-utils.so

And here is Wifi, again from my point of view:

merlin@ubuntu-dev:~/amng/release/src-rt-5.02L.07p2axhnd/bcmdrivers/broadcom/net/wl/impl69/sys/src/dongle/sysdeps/RT-AX86U/43684c0$ ls -al
total 2504
drwxrwxr-x 1 merlin merlin      20 Jun  5 00:11 .
drwxrwxr-x 1 merlin merlin      40 Jun  5 00:11 ..
-rwxrwxr-x 1 merlin merlin 2609402 Jun  5 00:11 rtecdc.bin

I can't debug it. I can't fix anything in it. I can't even tell what it's doing, how it's doing it, and why it's doing it. It is what it is: an opaque, closed, precompiled binary file.

I initially refused to support AiMesh due to the complete lack of control I had over it, and people complained. So I enabled it, with the caveat that it would be what it is, with zero possibility for me to have any impact on its behaviour. People will have to accept it for what it is, with its inherent limitations.

 

[dave14305]

@dave14305 that was interesting. No hw csum error on HND 5.04 (with kernel 4.19). Can't say if it's because of the newer SDK, or the newer kernel tho...

Maybe you could fix that too, while you're at it.

I started wondering if it was the incoming queries from the LAN or the outgoing replies to the LAN, but then I just stopped worrying once I realized we're stuck whichever direction we choose.

 

[Tech9]

People will have to accept it for what it is

I understand. The extra Asuswrt-Merlin features outweigh the quirks. My question is if there is anything in your firmware that you suspect may eventually interfere with integrated closed source components? There is a difference in how they work in Asuswrt and Asuswrt-Merlin. Users with single router will never see it and report it, but it's there. Do you know if Asuswrt 49447 for AX86U is based on the same GPL as Asuswrt-Merlin 386.7 to begin with? At least are the wireless drivers and AiMesh components the same?

 

[dave14305]

Do you know if Asuswrt 49447 for AX86U is based on the same GPL as Asuswrt-Merlin 386.7 to begin with

49447 = 49447
386.7 = 48966
49447 > 48966

A few things emerged after the initial merge.

History for release/src-rt-5.02L.07p2axhnd - RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - History for release/src-rt-5.02L.07p2axhnd - RMerl/asuswrt-merlin.ng

github.com

 

[RMerlin]

My question is if there is anything in your firmware that you suspect may eventually interfere with integrated closed source components?

Since I can't view the code, I have no way of knowing for sure. Could be something as simple as AiMesh checking the firmware version to determine compatibility, and since my version numbers are different from stock firmware, that alone would be enough to break things.

. Do you know if Asuswrt 49447 for AX86U is based on the same GPL as Asuswrt-Merlin 386.7 to begin with?

It's not. 386.7's RT-AX86U is based on 48966.

At least are the wireless drivers and AiMesh components the same?

Impossible to tell without having access to the source code. Even comparing binary files would be useless, since recompiles would result in slightly different binary files, as there are dynamic elements such as date stamps that will change between recompile of various elements. Linking can also potentially be slightly different, without implying code changes. Or there could be something as trivial as Asus adding a line of debugging output that would change the file without affecting it's actual working.

And the wireless driver is also only a fraction of the equation related to wifi behaviour. There are other Broadcom components that may affected it, such as the DHD driver (which loads the wireless firmware I listed in my previous post). The initialization/configuration code done by the rc daemon (that part is also closed source).

The same thing occurs in regards to the ACSD daemon. The daemon itself is closed source. And the code that configures it also is. So something such as people reporting that their 160 MHz channel more aggressively gets downgraded to 80 MHz could very well just be a configuration parameter that tells ACSD how many milliseconds of radar signaling is sufficient to force a channel downgrade (hypothetical scenario here). Wouldn't mean that acsd is broken, or even that acsd had changed.

Also, wifi "not working" does not always imply that something was broken. Let's take another hypothetical scenario here. Let's say you have a security cam that is not compatible with Airtime Fairness. Let's say you never disabled that feature because you didn't know, and your camera was connecting fine. Then at some point, Asus/Broadcom realizes that this feature is not working at all, and they fix the feature. Next driver release, your camera suddenly no longer connects. Does that mean that the new driver is broken? No. It means the new driver actually fixed something that was broken, and your 25$ Aliexpress security cam shows itself unable to work with that feature that is suddenly properly used by the router. This is why downgrading firmware to "fix the issue" is NOT proper troubleshooting. Proper troubleshooting is going through what I have been saying for years: if you have wifi issues, then disable the more esoteric/non-standard wireless settings, starting with Airtime fairness and Beamforming. Next step would be to reset your wireless settings to their defaults at both ends.

That's why "It was working in a previous version" is meaningless to me. It does not confirm that the newer driver is broken. It may actually be the complete opposite, and what's now broken is the client.

This scenario isn't as far fetched as you might think, since it actually happened before. A newer wireless driver implemented a specific error correction feature that wasn't working before. Suddenly, XBox is no longer able to maintain a stable wireless connection. So the "Optimize for xbox" setting was added to the Wireless setting. What's broken here is not the wireless driver, it's the XBox support for that feature, and the optimize toggle merely disables the setting in the wireless driver. Because Microsoft couldn't be bothered to fix their broken wireless client code. Maybe they eventually did, nobody knows.

 

[RMerlin]

A few things emerged after the initial merge.

Note that in the case of wireless debug output (which seems to still be enabled in their official release), I have a recompiled version of 48966, not a newer version of it. It's just recompiled with console debug disabled.

That's why I don't go out of my way to document which GPL version I'm using (beyond mentionning it in the changelog), because I'm not always using 100% that GPL code. Sometimes I have backported fixes from newer code. Like this guy:

rc: httpd: don't drop caches on HND routers (backport from 49335) · RMerl/asuswrt-merlin.ng@fe03424

Third party firmware for Asus routers (newer codebase) - rc: httpd: don't drop caches on HND routers (backport from 49335) · RMerl/asuswrt-merlin.ng@fe03424

github.com

49335 also has a number of fixes related to IPv6 DDNS support. I initially started backporting the changes, then decided not to mid-way as the changes were too complex, and would have required an extra beta cycle to properly test.

 

[RMerlin]

BTW, things aren't going to get any easier in the next few months, as 388 is almost here. Quite a few major changes involved, and Asus' roadmap for it mean that my (development) life is about to get more difficult.

Wireguard support is just the tip of the iceberg for 388.

 

[Skywise]

Anyone else seeing a slow memory leak on 386.7?

Did a dirty update from 386.5_2 on an AXE11000 - everything's working fine but I'm seeing a slow memory leak that's maxing out the RAM around 2 weeks up time that I wasn't seeing before forcing a reboot. I had the traffic analyzer on and read elsewhere that that might cause a leak so I turned that off but that seems to have had no affect. Running unbound and ntpmerlin as well - but I haven't changed/updated them since the update so I'm not suspecting them (yet). Also, I'm running the same unbound config on an AC-3100 that's still on 386.5_2 and there's no leakage there at all.

 

[Tech9]

This scenario isn't as far fetched as you might think

I usually read on 3x speed complaints about IoT devices for that same reason. It can be anything, like the neighbor trimming the grass with an electric trimmer, causing lots of RF noise. I know how it works and my question was more about router-to-router connections, in case you spot something on your end. The reason for my post above was your answer to another forum member with a question "What issues?". Thank you for the explanation why it can't be diagnosed and fixed. This is a different answer.

 

[bluepoint]

Anyone else seeing a slow memory leak on 386.7?

Did a dirty update from 386.5_2 on an AXE11000 - everything's working fine but I'm seeing a slow memory leak that's maxing out the RAM around 2 weeks up time that I wasn't seeing before forcing a reboot. I had the traffic analyzer on and read elsewhere that that might cause a leak so I turned that off but that seems to have had no affect. Running unbound and ntpmerlin as well - but I haven't changed/updated them since the update so I'm not suspecting them (yet). Also, I'm running the same unbound config on an AC-3100 that's still on 386.5_2 and there's no leakage there at all.

What you're seeing is the result of not dropping caches often when you login to the router, it's reverted back to not drop caches on HND routers in 386.7. The accumulation of RAM usage is normal, not to worry it will manage it himself by dropping caches at a certain percentage threshold. I've seen it done after three days but didn't take note at what % it did.

 

[Skywise]

What you're seeing is the result of not dropping caches often when you login to the router, it's reverted back to not drop caches on HND routers in 386.7. The accumulation of RAM usage is normal, not to worry it will manage it himself by dropping caches at a certain percentage threshold. I've seen it done after three days but didn't take note at what % it did.

Thanks! I've been seeing it get up to the 90%+ usage case (about 900mb out of 1024 on the AXE11000) - and noticed it after I felt I was getting more wifi drops than normal (though that may have been unrelated/normal and I just pounced on the high usage scenario as the cause)

 

[Clark Griswald]

BTW, things aren't going to get any easier in the next few months, as 388 is almost here. Quite a few major changes involved, and Asus' roadmap for it mean that my (development) life is about to get more difficult.

Wireguard support is just the tip of the iceberg for 388.

My network is working well and Griswald Easy to maintain, due to your hard work!
Every person here appreciates all that you have have been able to accomplish with Asus fw!
Having The Wife send a little something special your way via Paypal just to keep the Positive Mojo flowing!

 

[bluepoint]

Thanks! I've been seeing it get up to the 90%+ usage case (about 900mb out of 1024 on the AXE11000) - and noticed it after I felt I was getting more wifi drops than normal (though that may have been unrelated/normal and I just pounced on the high usage scenario as the cause)

No, wireless drops has nothing to do with the memory usage.

 

[Darkje]

@RMerlin may be a stupid question. But a question will never be stupid not asked right....

Dual wan is a long time pain caused by Asus. And as explained by you many times that this piece is closed source. Is there a way for you to add a new dual wan feature outside the closed source?