Release Asuswrt-Merlin 388.1 is now available for all supported Wifi 6 models

[juanantonio]

Is there any rule I could add to my iptables in order to gain access from my remote Wireguard clients to the router's LAN? I have already ticked option 'Intranet Access' on the Wireguard Server's config, but it seems no being working, because I can't access the router's gui from remote client, nor other devices in my LAN.

Thanks in advance,

 

[kernol]

I`m not going to keep track of the 15 x 15 (225) possible router combination to tell people what works and what doesn't.

I seem to have a habit of "touching a nerve" with you from time to time. Never intended - and above is not what I was suggesting you do.
This is a problem with a single - but very popular - (judging from number of firmware downloads) router - the RT-AX86U.

I devoted about two hours on one night to do at least a test setup to determine if the claim that "AiMesh cannot work when using an Asuswrt-Merlin node" was true, and my test showed that it wasn't the case. So I simply moved on to work on other things.

I am not aware of anyone on this forum making the statement in bold above - certainly not me because I have used Asuswrt-Merlin on many AiMesh nodes with different router combo's for several years. However I am far from alone in hitting the problem with the RT-AX86U.

My stance with AiMesh has been the same since day one: it's unsupported, it's known to have issues, and you get what you get out of it. If it works, great. If it doesn't, since there's nothing I can do about it, then I'm not gonna waste time or lose sleep over it...

I'm sorry - you have consistently and frequently waved the "closed source flag" at customer queries - so I really should have realised that you don't give a continental about AiMesh and all the other closed source bits.

I will butt out with that apology ... so no need to enter into a debate. I've got the message LOAD and clear!

 

[GHammer]

which is why my suggestion stands for a Change Log entry relative to the AX86U only. Without it folk [especially noobs] will keep flagging the same "bug"

Hardly anyone, especially the occasional visitor, reads the changelog. Just look at any thread here for confirmation.

 

[nhsal69]

Web history has some issues that Asus needs to fix, however, I'm uncertain if this problem is related. If you have done a reset to defaults and configured manual and minimum config, and it still happens, report it to Asus.

Thanks for that...

I've reverted to 386.8 and it all works again..

bit weird.

 

[bluepoint]

It is often not possible for the dns server to come from dhcp. Many devices have hardcoded dns.

Dns director also historically did not control all dns queries at all, it only controlled unencrypted dns queries.

Not true. DNS director will intercept all LAN DNS queries as long as you confiigure it correctly be it hardcoded or not. The only time DNS queries are bypassed is if your LAN client's browser or apps uses DOH. If you really want to control them you need to figure out how to turn off DOH.

 

[dmillerzx]

Thanks for that...

I've reverted to 386.8 and it all works again..

bit weird.

On a AX86U loading the 'web history' page for me crashes the webserver, takes a bit to to recover, happens every time. Trying to figure out a way to turn off until it starts to play nicely.

 

[skeal]

I`m not going to keep track of the 15 x 15 (225) possible router combination to tell people what works and what doesn't. There are simply too many variables involved, and more than a few people who claimed initially that their specific setup didn`t work would come back later saying that it was now working following a reset. I devoted about two hours on one night to do at least a test setup to determine if the claim that "AiMesh cannot work when using an Asuswrt-Merlin node" was true, and my test showed that it wasn't the case. So I simply moved on to work on other things.

Sorry, I didn't mean to suggest something to increase your workload. I was, however, talking about 1 specific router the AX86U, not the other 14x14 arrangement possibilities. Again my apologies.

 

[RMerlin]

I seem to have a habit of "touching a nerve" with you from time to time

It wasn`t targeted specifically at you, other peoples have also asked for the same thing.

I am not aware of anyone on this forum making the statement in bold above

@Tech9 has been posting multiple times that "Aimesh is broken with Asuswrt-Merlin on nodes and you need to use the stock firmware". My tests proved that blanket statement to be inaccurate, that it remains on a per-model basis.

I'm sorry - you have consistently and frequently waved the "closed source flag" at customer queries - so I really should have realised that you don't give a continental about AiMesh and all the other closed source bits.

The real question is, even if I cared about it, what could I do about it? Absolutely nothing... So it makes no sense for me to get frustrated over an issue I cannot change.

 

[128bit]

Hi all!
Bundle AX86 + AX86S
On 388.1 The WEB interface shows that there is no cable connection, although everything works fine.
At the same time, everything looks OK in the WEB interface on Firmware version 3.0.0.4.388.21709.

Spoiler

View attachment 46066View attachment 46067

i saw similar behavior not using mesh. check you wan -> dual wan tab and ensure that the "primary wan" is set correctly. for me, network map showed "no connection" even though i was working fine.

 

[128bit]

vpn director fails on 388 - but it's somewhat intermittent.

i have several defined clients in director. when selecting enable/disable for specific windows clients, i've noticed that the public ip doesn't always change. it fails 25-33% of the time with 2 different win clients.

the test: after a disable, the public vpn ip and not the isp's ip may still be active. this behavior persists after clearing browser cache (ctrl+f5) and rechecking the ip. it can work properly on occasion, but eventually, it will fail to revert.

fwiw, i'm using tools such as "what's my ip" from different vendors as well as logging attempts to youtube tv, reboots, etc. i'm talking over 15 hours total since sunday. the only way to resolve this was to change the "service state" to "off" on the vpn client tab. so i'm back on 386.72 where all's well. and yes, i've tried 2 different vpn providers.

this is my 2nd post.

 

[fourty6and2]

On AX6000, since the upgrade, I got continuous 5G disconnects, network just disappears for a couple of mins, to come back later 2.4g works fine. Not happy.

I had a similar experience when upgrading my AX86U via a dirty flash. Mine was resolved by doing a full reset (nuclear) and setting up from scratch.

 

[JCompagner]

for me upgrading my setup, did cost me quite some time to get back to a usable state

I think others also reported similar stuff, but my setup is that i have 1 AX86U as a mesh router, then 1 AX86U as a mesh point and a AX58U as another mesh point.
The AX86U mesh is connected to the 2.5GB ports so with an ethernet
the AX58U is connected to a 1GB from the router to the WAN poort of the AX58U.


i upgraded first my AX58U, that seems to be fine, also the router reported everything was there and connected and also the connection was "fantastic"

Then i upgraded the mesh point AX86U that at first seems fine, and now i am not 100% sure what the router reported, because i did see it was upgraded and still in my mesh
so i also upgraded as last the AX86U Router..

Then i did notice that it suddenly says "bad connection" and so on, but it seemed to work so i ignored it for now.

Then a bit later in the afternoon i suddenly noticed that my wifi coverage of upstairs where the AX86U should be, didn't work anymore (couldn't see certain devices anymore)

So i suddenly noticed that the AX86U was completely out of my mesh, and what ever i did i didn't get it back, i even did a full reset on that one and then let the main router try to find it again.
I even moved it next to the main router through wifi or through a small cable.. and try to find it again. nothing worked i couldn't get it back. (but the mesh AX86U (that was the mesh point) did work as standalone and so on)

then i uploaded the previous firmware back on the AX86U mesh point, but still the main router wouldn't find it,
then i uploaded the previous firmware back to the router, and then bang it did find the mesh point again and in a few minutes everything was working again..

So for now i will skip this release and maybe also the next to not get into this again..

until now on the AX58U it is working find and that one is still in the mesh, it could be that i can also have the none router AX86U to this firmware and that the real problem is in the main router one that suddenly has weird stuff.

 

[eleVator]

VPN Director works differently in 388.1 GT-AX6000 then on my RT-AC86U.
Used to have two VPN clients running with different exit points. VPN director was set to route all through VPN1 and then specific hosts were set to use VPN2.
This doesn't seem to work in 388.1 and i would have to manually add each host with a rule in VPN Director but i don't need it right now, just dropping the info here.

 

[capncybo]

@JCompagner Thank you for submitting such a detailed report. Within the details I think (perhaps you touched on something).
You mentioned the first RT-AX86U node as being connected via the 2.5G Port during initial setup.
From my personal experiences with AiMesh on RMerlin & lesser node routers...
I connected the nodes momentarily (or permanently) to the Regular Ethernet Ports during initial setup.
(Note: if The Node was to be a WiFi node... I powered it down, disconnected it, relocated the node & powered it back up after the initial setup)

I'm just wondering if some of these AiMesh issues with the RT-AX86U (in particular)...
might have something to do with using the 2.5G Data Port?

 

[tarzan2000]

i saw similar behavior not using mesh. check you wan -> dual wan tab and ensure that the "primary wan" is set correctly. for me, network map showed "no connection" even though i was working fine.

Not in this case.
In the settings of the global network, everything is fine

Spoiler

 

[Tech9]

@Tech9 has been posting multiple times that "Aimesh is broken with Asuswrt-Merlin on nodes and you need to use the stock firmware".

No, "Wireless AiMesh node discovery is broken when Asuswrt-Merlin is used on the main router". All 386 versions and on most popular models RT-AC68U, RT-AC86U and RT-AX86U. The same on 388 version on RT-AX86U to 386 nodes. There are reports WPS is broken on some Asuswrt-Merlin versions and perhaps the issues are related. I have the ability to flash and rinse multiple times - something most users with routers providing Internet can't afford to do. I've tested from 384 through 386 to 388. Strangely enough I had few successful node discovery attempts on 384 (AiMesh 1.0), but none on 386 and current 388 (AiMesh 2.0). I can demonstrate this behavior with any available router + node combination.

My stance with AiMesh has been the same since day one: it's unsupported, it's known to have issues, and you get what you get out of it. If it works, great. If it doesn't, since there's nothing I can do about it, then I'm not gonna waste time or lose sleep over it...

No, your stance is here - https://github.com/RMerl/asuswrt-merlin.ng/wiki/AiMesh

"Asuswrt-Merlin 384.13 adds full support for AiMesh (both as a primary router and as a node)."
"The process is identical to that under the stock firmware. It is recommended to follow the official documentation, on the Asus website."

Sorry, but nothing even close since AiMesh 2.0 was introduced and it doesn't work on most popular router models. This Wiki page has to be changed to what I quoted from your post above. Otherwise people read it and then wonder what's going on, come here and ask questions. You always ditch everyone with "not in my control" or "just ignore it". Since it's working properly in stock Asuswrt something you added on top breaks it. The same with Wi-Fi questions you just ignore. I test with the weirdest clients I can find and they work in Asuswrt, but some don't even connect with Asuswrt-Merlin. Something added on top interferes with Wi-Fi as well and perhaps all AiMesh, Wi-Fi and WPS issues are connected.

I post #98 in this very same thread I said "runs and drives" intentionally. This is how most people around test the releases. If the router boots up and the devices connect - all good, let's go! What I see though is most Asuswrt base bugs transferred + some more on top + broken core features like AiMesh and Wi-Fi connectivity. One of my test devices is a Linksys E5400 router in Bridge mode (like Media Bridge in Asuswrt). I reset this router every time and set the Bridge mode again. When RT-AX86U runs Asuswrt after rebooting the router the connection to the wireless bridge restores automatically. When RT-AX86U runs Asuswrt-Merlin 388.1 - it doesn't, the wireless bridge has to be rebooted too. The same wireless settings on AX86U in Asuswrt and Asuswrt-Merlin. I know "nothing is changed", but I see the difference and the negative effect is more than obvious.

In my opinion Asuswrt-Merlin was better when the development was closer to "primary goals are to enhance the existing firmware without bringing any radical changes". Right now the number of changes on top of closed source firmware and ever expanding number of supported router models with automatically generated untested builds are moving the project to what DD-WRT is - use at your own risk. Have you noticed the beta/release threads got much longer? More people like @kernol will be touching nerves because there are issues. We all know and appreciate what you do, but listen a bit more to what users are saying instead of "I'm going to ignore all xyz related questions from now on".

 

[MoonPie2000]

Thanks again for a quality product keeping our Asus routers relevant and secure. I am sure I can speak for the community in stating we appreciates your commitment and dedication to the cause

 

[RMerlin]

No, "Wireless AiMesh node discovery is broken when Asuswrt-Merlin is used on the main router". All 386 versions and on most popular models RT-AC68U, RT-AC86U and RT-AX86U.

And yet I had zero problem with the node discovery when I tested it myself, hence it works on some combinations.

"Asuswrt-Merlin 384.13 adds full support for AiMesh (both as a primary router and as a node)."

I added support, which basically meant that I enabled it, and it works. That does not mean that *I* provide technical support for it, as I have no control over it.

but listen a bit more to what users are saying instead of "I'm going to ignore all xyz related questions from now on".

After doing this for 10 years, I know from personal experience the difference between a proper test and an anecdotal report, and sadly a lot of users don't (not that I expect every user to be a skilled IT technician). I even conducted a little experiment back in the day, before you were around. There were an increasing number of people complaining about Wifi performance on their RT-N66U, and blaming the firmware for it, so I generated three test builds. Two had the exact same wireless driver (so, consider one of them to be the placebo), and the third used a different driver version. All I said to testers was to tell me which of the three was most stable. Guess what? A number of people were claiming to see a difference between version 1 and 2, which I knew to be the exact, 100% identical code - just recompiled with a different filename. That was when I decided that I could continue to devote countless hours to test every single report or provide testing procedures, to see 90% of them be complete placebo or bogus, or I could focus on things that actually made sense to devote time to. If I personally tested and investigated every single wireless report that was posted on these forums, you know what? I wouldn't have released a single new version in 2022, and I wouldn't have fixed any real issue either, since I have no control over those issues.

A lot of the wireless issues report come from broken IoT clients, which I can't do anything about, but tell people to ditch that 10 years old wireless camera and buy something more modern.
A lot of them come from configuration issues, and my attempts at maintaining a post explaining the best recommended settings was completely wasted since myself and other people kept repeating the same advices that were published in that post. Lots of wireless printers for instance will fail to connect if you enable Airtime Fairness on your router, something that Asus were enabling by default.
A lot of people are comparing driver version 2000 with stock firmware's driver version 3000, and assume that I broke it if it behaves differently - it's rather that Asus broke it in version 2000, and fixed it in the mean time between the moment I received code and issued a release, and the time they issued an update that included the fix. Nobody will talk however about the times where they issued a new, broken version (like that version 2000) and my firmware was unaffected (because I was still on version 1000). A<->B testing of a wireless performance is meaningless if A and B are not the same wireless driver.

Another more recent example: about a week ago, someone reported a particular issue, which seemed to be a plausible problem. So I spent an entire evening getting a test setup, renting a test VPS and configuring that VPS so I could do actual remote testing to reproduce the user's scenario. And I could never reproduce the issue. So at the end of the evening I come back to the forums, track down the initial report to ask for more details... and the report had been deleted by the user, most likely because he figured out it was a configuration issue.

Have you noticed the beta/release threads got much longer?

The 388 beta cycle was much longer than before because it was a major change, both in terms of GPL merge and the development of the WireGuard integration. That meant a lot of things that needed testing. And a significant number of issues were reported, and fixed (whenever they were under my control to fix). Look at the commit changes between beta releases, many of these were from user reports.

In my opinion Asuswrt-Merlin was better when the development was closer to "primary goals are to enhance the existing firmware without bringing any radical changes".

For the past 3 years or so I have been VERY conservative about making so-called radical changes. I keep bringing that up in my end of year reports. When I do a major GPL merge (384->386 and 386-> 388) I generally do a pass at the code and drop some of the changes I might have made in the past to address some issues that no longer seem to be problematic. I turn down a lot of feature and change requests specifically to avoid such radical changes and to keep things easier for me to merge in. The only radical change that I have made over the past year or so is VPN Director, and it's a standalone feature that won't integrate with the rest of the firmware code.

So, which radical change are you talking about here? I stopped systematically updating some components like curl and dnsmasq because one update out of two brought in new issues, for example.

I have nobody to do bug triage for me. And personally investigating every single report would take 100% of my time, and would effectively bring all development to a complete stop. So, I decide where my time is best spent. If something is plausible and is under my control, then I will spend time investigating the issue. If something is more likely to be either a user configuration issue or something outside of my control, then I focus on something else where I can actually do some good. If that's not acceptable to you, then by all means, go back to the stock firmware, and don't use my firmware. Because there's simply nothing more that I can do than what I am already doing.

We could be here for days debating how I manage this project. The bottom line is, I manage it as best as is possible for a single person to do so, and out of the 100K+ users out there, the number of genuine complains is very low. I'm not going to devote any more of my energies trying to defend the way that I manage this project, because there is no way I can please everyone with the resources at my disposal. So it's up to the users to take it, or leave it, as it is.

 

[128bit]

No, "Wireless AiMesh node discovery is broken when Asuswrt-Merlin is used on the main router". All 386 versions and on most popular models RT-AC68U, RT-AC86U and RT-AX86U. The same on 388 version on RT-AX86U to 386 nodes. There are reports WPS is broken on some Asuswrt-Merlin versions and perhaps the issues are related. I have the ability to flash and rinse multiple times - something most users with routers providing Internet can't afford to do. I've tested from 384 through 386 to 388. Strangely enough I had few successful node discovery attempts on 384 (AiMesh 1.0), but none on 386 and current 388 (AiMesh 2.0). I can demonstrate this behavior with any available router + node combination.



No, your stance is here - https://github.com/RMerl/asuswrt-merlin.ng/wiki/AiMesh

"Asuswrt-Merlin 384.13 adds full support for AiMesh (both as a primary router and as a node)."
"The process is identical to that under the stock firmware. It is recommended to follow the official documentation, on the Asus website."

Sorry, but nothing even close since AiMesh 2.0 was introduced and it doesn't work on most popular router models. This Wiki page has to be changed to what I quoted from your post above. Otherwise people read it and then wonder what's going on, come here and ask questions. You always ditch everyone with "not in my control" or "just ignore it". Since it's working properly in stock Asuswrt something you added on top breaks it. The same with Wi-Fi questions you just ignore. I test with the weirdest clients I can find and they work in Asuswrt, but some don't even connect with Asuswrt-Merlin. Something added on top interferes with Wi-Fi as well and perhaps all AiMesh, Wi-Fi and WPS issues are connected.

I post #98 in this very same thread I said "runs and drives" intentionally. This is how most people around test the releases. If the router boots up and the devices connect - all good, let's go! What I see though is most Asuswrt base bugs transferred + some more on top + broken core features like AiMesh and Wi-Fi connectivity. One of my test devices is a Linksys E5400 router in Bridge mode (like Media Bridge in Asuswrt). I reset this router every time and set the Bridge mode again. When RT-AX86U runs Asuswrt after rebooting the router the connection to the wireless bridge restores automatically. When RT-AX86U runs Asuswrt-Merlin 388.1 - it doesn't, the wireless bridge has to be rebooted too. The same wireless settings on AX86U in Asuswrt and Asuswrt-Merlin. I know "nothing is changed", but I see the difference and the negative effect is more than obvious.

In my opinion Asuswrt-Merlin was better when the development was closer to "primary goals are to enhance the existing firmware without bringing any radical changes". Right now the number of changes on top of closed source firmware and ever expanding number of supported router models with automatically generated untested builds are moving the project to what DD-WRT is - use at your own risk. Have you noticed the beta/release threads got much longer? More people like @kernol will be touching nerves because there are issues. We all know and appreciate what you do, but listen a bit more to what users are saying instead of "I'm going to ignore all xyz related questions from now on".

wow! now that was a mouthful and i can certainly understand your frustration. my suggestion would be for you two to have a private convo about this. here's why. . .

our dearest and seemingly only developer has to be swamped! you kind of eluded to it yourself in your post. we all rave about the merlin goodies, but we likely have little insight to his workload and stress. with past issues, your comments have helped me and likely countless others. you and people like you that share, are a big part of the success of the board (old expression for blog).

 

[Tech9]

Because there's simply nothing more that I can do than what I am already doing.

I understand, but don't just ignore issues reported because they are based on something real. You know I just play with the routers - what I do is read about issues and attempt to replicate. Some reported issues I simply can't see no matter what. But AiMesh and Wi-Fi related - very often. I'm spending some personal time trying to find usable clues for you. I don't know how it works under the hood, but I see what it does. When I see something wrong I report it. At least I tried in few beta threads - thread closed, "not in my control" and now straight "it is what it is". Some folks are even blamed they imagine issues. What's the point of the beta/release threads then? Just release the firmware and don't accept any feedback.

i can certainly understand your frustration.

No frustration at all @128bit. I can try to help with my free time and available hardware or I can just ignore it and do something better. What I don't like in last few releases is a lot of people comment about similar issues and they are all ignored. I asked for a small note on Asuswrt-Merlin website about AX58U/AX3000 V2 - ignored. It will save a lot of questions and prevent mistakes - no, not happening. I tested for hours AiMesh combinations on 3 different firmware bases - ignored, it works here between two routers. Questions about Asuswrt-Merlin AiMesh issues come every day and we can help - nope, let them try. It's like the main goal is generating more threads on SNB Forums. Obviously there is something else I don't know about.