What's new

Beta Asuswrt-Merlin 388.1 Beta is available for select models

  • 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.
eventhough the AX86s will probably still be overkill for my home network.

Not this beta related but may help you - I've got one AX86S for a friend of mine for CAD180 about a month back. It was CAD200 last week at BestBuy. The U and S versions perform exactly the same, if you don't hit the obvious S limitations. I've tested both side by side on my home 500/30 cable. Both perform worse than AC86U on lower 36-48 channels, good on 149-161. I don't know about DFS range, too close to Pearson International flight path.
 
I don't know if this is the same problem but I ran into dns problems after upgrading to 388.1b. I had DoT configured on the router for ControlD and after the upgrade dns resolution failed almost completely. If I changed to Cloudflare or Quad9 it worked again. Not sure what happed, had to make a workaround using AdguardHome so the family could access the net again so I didn't have much time to troubleshoot but I think I saw signs of dnssec causing problems and SERVFAIL, not sure though.
Opportunistic mode works so I don't know what has changed, always used to run strict mode.
 
My Samsung s20fe running Android 12 now has an issue connecting to my rt-ax86u if Android private dns setting is set to 1dot1dot1dot1.cloudflare-dns.com

I get a notification that the WiFi has no internet and private dns cannot be accessed.
Android refuses to flow any data to the WiFi even for IP addresses and instead pushes everything to mobile network. Perhaps it is considered an unsafe network because Private Dns was blocked?
Setting androids private dns to off allows the device to connect to wifi/internet.

I do use DoT on the router and use Dns director to redirect clients to the router.

This issue did not exist on 386.7_2
DNS director has started blocking port 853 as well as port 53 when redirection is set to anything other than no redirection. If you're using DNS Director for an Android client using Private DNS you can add it to the rule list and select "no redirection". Had the same issue with the Alphas (kids stared telling me their phones weren't working :) - using Private DNS so that kids' mobiles are filtered via CleanBrowsing profiles).
 
Last edited:
UPDATE 3: I can replicate this issue by using DNS Director to use the router as DNS for any one of the devices routed through the Wireguard tunnel. When you apply the setting, somehow it makes Wireguard use the router as DNS instead of the preconfigured DNS in the client itself, in my case causing a DNS leak. Again a Wireguard client disable
If I have understood @RMerlin right Wireguard dns is handled using firewall dnat, same as DNS Director. Look at you firewall rules to determine what is happening, I.e:
Code:
iptables -nvL PREROUTING -t nat
perhaps the Wireguard rules does not get re-applied correctly or something ends up in the wrong order.

By the way, if you use DNS director to alter dns of a wireguard client, which rule should take precedence in your opinion? I actually dont know... by heart I would say DnsDirector but then this would probably conflict with global settings... if not, there would not be any other way of redirecting wireguard clients, at least not one by one.
Anyone know how this is prioritized?
 
Last edited:
I have my main router AX6000, and a AX68U running this beta. AiMesh is broken when both devices are running this build. The AX6000 will show the AX68U as a node that can be added. However it will go through the process, seems the AX68U even reboots while it tries to add it as a node. However it's loading percentage will hit around 50% before a error message comes up saying the node failed to be added. I spent like 45 minutes trying to get this to work, no luck.

However in my case I do run my AX68U as a wired mesh node. So I can still just have it in AP mode, and still serve other devices. Just the mesh system itself is broken, with both devices running this beta build. Anyways I know others have reported this issue as well. Just wanted to add it's not working for me either.
 
12+ hours of no issue run time in RT-AX3000 after dirty upgrade to 388 beta1 from most recent 388 alpha.
 
If I have understood @RMerlin right Wireguard dns is handled using firewall dnat, same as DNS Director. Look at you firewall rules to determine what is happening, I.e:
Code:
iptables -nvL PREROUTING -t nat
perhaps the Wireguard rules does not get re-applied correctly or something ends up in the wrong order.

By the way, if you use DNS director to alter dns of a wireguard client, which rule should take precedence in your opinion? I actually dont know... by heart I would say DnsDirector but then this would probably conflict with global settings... if not, there would not be any other way of redirecting wireguard clients, at least not one by one.
Anyone know how this is prioritized?
I think what is going on is; if you configure a device that is currently running through your Wireguard client on the router, to use a different DNS service than what the router Wireguard client is configured for, then when you apply the setting in DNS Director to do this, it changes the DNS used by the router Wireguard client, to the DNS configured in the DNS Director interface that you just applied. In my case DoT Cloudflare because I selected "Router", this causes a DNS leak. I use all Torguard DNS on my router Wireguard client. Before doing this of course I have no leaks. Yes it's likely a routing rule, as no settings in the router Wireguard client are altered.
 
I have my main router AX6000, and a AX68U running this beta. AiMesh is broken when both devices are running this build. The AX6000 will show the AX68U as a node that can be added. However it will go through the process, seems the AX68U even reboots while it tries to add it as a node. However it's loading percentage will hit around 50% before a error message comes up saying the node failed to be added. I spent like 45 minutes trying to get this to work, no luck.

However in my case I do run my AX68U as a wired mesh node. So I can still just have it in AP mode, and still serve other devices. Just the mesh system itself is broken, with both devices running this beta build. Anyways I know others have reported this issue as well. Just wanted to add it's not working for me either.
This is usually just a problem with AI Mesh "pairing". Make sure the two routers are sitting right next to each other
 
I have my main router AX6000, and a AX68U running this beta. AiMesh is broken when both devices are running this build. The AX6000 will show the AX68U as a node that can be added. However it will go through the process, seems the AX68U even reboots while it tries to add it as a node. However it's loading percentage will hit around 50% before a error message comes up saying the node failed to be added. I spent like 45 minutes trying to get this to work, no luck.

However in my case I do run my AX68U as a wired mesh node. So I can still just have it in AP mode, and still serve other devices. Just the mesh system itself is broken, with both devices running this beta build. Anyways I know others have reported this issue as well. Just wanted to add it's not working for me either.
Try using the latest Asus baseline build on the AX68U AiMesh node (as opposed to Merlin 388.1 beta1). I had some issues with RT-AX86U nodes (Merlin beta1) under my AX6000 primary router (Merlin beta1) that were resolved by reverting to the Asus baseline on the nodes (AX6000 remains on Merlin beta 1)
 
This is usually just a problem with AI Mesh "pairing". Make sure the two routers are sitting right next to each other
I tried that. At first they were probably 20+ feet apart, with walls, and such in the way. I ended up having the AX68U within 3-4 feet of the AX6000, didn't help.
 
DNS director has started blocking port 853 as well as port 53 when redirection is set to anything other than no redirection. If you're using DNS Director for an Android client using Private DNS you can add it to the rule list and select "no redirection". Had the same issue with the Alphas (kids stared telling me thir phones weren't working :) - using Private DNS so that kids' mobiles are filtered via CleanBrowsing profiles).
Manually adding devices the router blocked to an exclusion list is a temporary work around.
Eg my fix at the moment is to entirely stop using dns director.
 
A bug, I think.
Some devices that are disconnected show as connected with their leased IP.

AX88U
Happened to me earlier already with the first device I disconnected on the same switch.
Shows as well in the APP itself
1667854294519.png
 
AX 68U. Client list remains empty. Bandwidth Monitor shows the spinning circle and nothing else.
Besides RT-AX68U, I assume the client list and Bandwidth Monitor work on all other models?
 
@SomeWhereOverTheRainBow @RMerlin

I had some time after work to test.

First I cleared my log and set it to log everything.

Then, I went to the Privacy tab and withdrew per @SomeWhereOverTheRainBow's suggestion.

Then I went to AIProtection and enabled it. It prompted me to accept the agreement, I accepted, it did it's percentage based count until it said "Complete" and then the router rebooted.

It then proceeded to bootloop 2-4 times.

I caught it and turned off AIProtection and saved my log.

"Crashlog" shows up twice in this log.

Thanks everyone.

EDIT:

I tried attaching the file itself, but that doesn't seem to be working. Here are a few snippets of log from where the "crashlog" appears.


EDIT 2:

Created a pastebin:

 
Last edited:
Besides RT-AX68U, I assume the client list and Bandwidth Monitor work on all other models?
The RT-AX68U image is missing a library needed by networkmap, which is why the networkmap is empty on this model (networkmap fails to run).
 
I tried attaching the file itself, but that doesn't seem to be working. Here are a few snippets of log from where the "crashlog" appears.
Use a free pastebin account and leave the link here instead.
 
I have my main router AX6000, and a AX68U running this beta. AiMesh is broken when both devices are running this build. The AX6000 will show the AX68U as a node that can be added. However it will go through the process, seems the AX68U even reboots while it tries to add it as a node. However it's loading percentage will hit around 50% before a error message comes up saying the node failed to be added. I spent like 45 minutes trying to get this to work, no luck.

However in my case I do run my AX68U as a wired mesh node. So I can still just have it in AP mode, and still serve other devices. Just the mesh system itself is broken, with both devices running this beta build. Anyways I know others have reported this issue as well. Just wanted to add it's not working for me either.
Having the same problem on a AX68U, my AX88Us both upgraded and running mesh router and node fine, but my AX68U refuses to be set back up as a mesh node. I've reset it and factory reset it and it always fails at the 50% level both wired and on wireless.
 
I have my main router AX6000, and a AX68U running this beta. AiMesh is broken when both devices are running this build. The AX6000 will show the AX68U as a node that can be added. However it will go through the process, seems the AX68U even reboots while it tries to add it as a node. However it's loading percentage will hit around 50% before a error message comes up saying the node failed to be added. I spent like 45 minutes trying to get this to work, no luck.

However, in my case, I do run my AX68U as a wired mesh node. So I can still just have it in AP mode, and still serve other devices. Just the mesh system itself is broken, with both devices running this beta build. Anyways I know others have reported this issue as well. Just wanted to add it's not working for me either.
I had the same issue except I'm running an RT-AX88U as the main router with an RT-AX68U node. Using 388.1 beta_1 on the main router, I tried loading beta_1 on the AX68U node and it just disappeared on the AiMesh page. I reset the AX68U, and it found it but when the percentage configuration went to 75%, it stated that it was unable to connect. I downgraded the node back to 386.7_2, reset it, and connected it, and all is well again with the AX88U running 388.1 beta_1 and the AX68U node running 386.7_2.
 
Updated my post. Thanks.
Unfortunately there is no info about the crash in the log, and since I can't reproduce it and it happens with a closed source component, then probably nothing I can do about it. You might try doing a factory default reset to see if it resolves your issue.
 
Status
Not open for further replies.

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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