Beta Asuswrt-Merlin 388.1 Beta is available for select models

[nzwayne]

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.

If your AiMesh node you wanting to add has rmerlin code installed, I've found in my home setup, you cannot add in wireless mode, only if ethernet cable is connected to the unit your adding. Using stock firmware on the node your adding, you can add via wireless and cable modes.

 

[dbell]

GT-AX6000 running on 388.1 Beta. When I update the downstream AiMesh RT-AX86U units to 388.1 Beta from the ASUS stock 388 level the AiMesh panel shows both RT-AX86U's show they lose their Ethernet connection. The RT-AX56U on 388.1 Beta with ethernet connection no issues.
I have power cycled off/on the GT-AX6000 and RT-AX86Us and no change. What does resolve this quirk is re-installing the RT-AX86U stock firmware that was previously installed: RT_AX86U_AX86S_300438820566. 100% re-creatable; 388.1 beta loaded on the RT-AX86U's no Ethernet connection shown, Stock 388 firmware loaded Ethernet connection shown. View attachment 45217View attachment 45220

I am seeing same between my two AX86U's which are hard-wired backhaul on the 2.5G port - but the connectivity is fine and port status graphic is green:

 

[RMerlin]

When you do that, do you have a section to "check for signatures" on your firmware page?

That section becomes visible whenever you accepted the Trend Micro EULA and are using any of the features that are tied to their bwdpi engine. Same with the option to withdraw from the Trend Micro EULA, the option becomes visible once you accept it.

Huh. Strange. You can enable all three AIProtection features on your AXE16000 just fine?

Yes. This is actually my main router, I have the first two options always enabled, and I was able to enable and re-disable the third option when I tested it last night (the device blocking one) without any problem. I also have both Adaptive QoS and Traffic Analyzer enabled (both of which also use the bwdpi engine).

One difference is you seem to have IPv6 enabled, which I don't. Can you confirm if the same issue happens with IPv6 disabled?

Things to try:

See if you would be able to enable AiProtection but keep only one single option enabled at a time, see if a specific option triggets it

Also try opening an SSH console, and running the following command:

tail /var /log/ syslog.txt -f

(without the spaces between the var-log-syslog portion - the forums didn't like the full path)

While running, try enabling AiProtection. See what are the last syslog lines that appear right before the reboot.

 

[Deleted member 22229]

AX58U updated to Beta 1 upon release. 2 days uptime no issues what so ever rock solid. Thanks !!

 

[shabbs]

APs still solid here after almost 48 hours.

*quietly misses the uptime thread*

 

[skeal]

Further information about the DNS Director issue I stumbled upon. As stated before when you hit apply on the DNS Director page to alter the DNS of a device running through the Wireguard client, it changes the DNS used by the Wireguard client to in this case "Router". If you then disable and re-enable the Wireguard client, it restores it's DNS settings set in the client. DNS Director has no effect on the device needing different DNS at this point, as the DNS leak test shows my Torguard DNS when the "Router" DNS is DoT Cloudflare. DNS Director and the new Wireguard client have a conflict in this way. I have no idea about the Wireguard Server end of things. There are no logs from DNS Director and the Wireguard logs show the device forced to use the Torgaurd DNS Servers, no where can I find a Wireguard log showing that the DNS on that device is different.

 

[dbell]

I know AIMesh is closed-source, but just reporting...

388.1 beta AX86U with AX86S hardwired node, ethernet backhaul only turned on.

If the node is on stock, AIMesh works fine.

If the node is on merlin, it reports as connection being severed, but still assigns clients there.

And the clients can still access the local network and internet right ? At least mine can with my twin AX86U mesh. Seems like a cosmetic / reporting issue rather than an actual connectivity problem.

 

[kernol]

I am seeing same between my two AX86U's which are hard-wired backhaul on the 2.5G port - but the connectivity is fine and port status graphic is green:
View attachment 45279

For recent Merlinware versions on at least the RT-AX86U "something" in his code has conflicted with AiMesh Node linking.
AiMesh is closed source - so I guess RMerlin has no way of determining what part of his code is causing the issue.
Solution is simple - just stick to stock firmware on all the AiMesh Nodes ... [ see mine pictured below on stock].


Special thanks to @RMerlin for all his hard work on this particular version upgrade which, judging from all the commits, has been a LOT of work!
Of particular cheer for me [and no doubt other RT-AX86U owners] is the included

• fix for channelling Guest Wifi1 on both 2.4GHz and 5GHz through OpenVPN Clients [no longer need Yazfi to route them]; and
• updated WiFi drivers which [so far] hold on to the 160 MHz for AX clients without reverting to 80MHz.

Everything else per my signature is working properly well {Thumbs-Up}. .

 

[Jumpstarter]

388.1 will not work with the AC88U. It will only work with the AX88U.

Sorry the AC was typo, I meant AX. I got it to flash, but I had to restore to get it to work.

 

[Jumpstarter]

Further information about the DNS Director issue I stumbled upon. As stated before when you hit apply on the DNS Director page to alter the DNS of a device running through the Wireguard client, it changes the DNS used by the Wireguard client to in this case "Router". If you then disable and re-enable the Wireguard client, it restores it's DNS settings set in the client. DNS Director has no effect on the device needing different DNS at this point, as the DNS leak test shows my Torguard DNS when the "Router" DNS is DoT Cloudflare. DNS Director and the new Wireguard client have a conflict in this way. I have no idea about the Wireguard Server end of things. There are no logs from DNS Director and the Wireguard logs show the device forced to use the Torgaurd DNS Servers, no where can I find a Wireguard log showing that the DNS on that device is different.

I can confirm, I too experienced this with the director of dns as well. Did you find a work around?

 

[Jumpstarter]

For recent Merlinware versions on at least the RT-AX86U "something" in his code has conflicted with AiMesh Node linking.
AiMesh is closed source - so I guess RMerlin has no way of determining what part of his code is causing the issue.
Solution is simple - just stick to stock firmware on all the AiMesh Nodes ... [ see mine pictured below on stock].
View attachment 45293

Special thanks to @RMerlin for all his hard work on this particular version upgrade which, judging from all the commits, has been a LOT of work!
Of particular cheer for me [and no doubt other RT-AX86U owners] is the included

• fix for channelling Guest Wifi1 on both 2.4GHz and 5GHz through OpenVPN Clients [no longer need Yazfi to route them]; and
• updated WiFi drivers which [so far] hold on to the 160 MHz for AX clients without reverting to 80MHz.

Everything else per my signature is working properly well {Thumbs-Up}. .

Pitta I run merlin on my nodes just fine. At the end of the day a node is just a node. Other than that, I share your same assessment.

 

[RMerlin]

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.

Re-applying VPN Director rules or restarting the firewall wasn't reapplying the DNS redirection rules for WGC clients. Fixed.

 

[blackfireball5]

One difference is you seem to have IPv6 enabled, which I don't. Can you confirm if the same issue happens with IPv6 disabled?

Disabled IPv6. Same issue with bootloop occurs when AIProtection toggled on.

Things to try:

See if you would be able to enable AiProtection but keep only one single option enabled at a time, see if a specific option triggets it

I have determined that any of the three options turned on by themselves cause me to bootloop, but I can have the main toggle on with all three options disabled.

Going to try the SSH suggestion now.

And then depending how that goes, i'm going to dirty flash the same 388.1 beta again to see if that helps.

 

[blackfireball5]

Also try opening an SSH console, and running the following command:

tail /var /log/ syslog.txt -f

(without the spaces between the var-log-syslog portion - the forums didn't like the full path)

While running, try enabling AiProtection. See what are the last syslog lines that appear right before the reboot.

Tried this but get this:

jon@GT-AXE16000-A230:/tmp /home /root# tail /va r/log /syslog.txt -f
tail: can't open '/var /log /syslog.txt': No such file or directory
tail: no files

(I had no spaces in the file paths)

 

[RMerlin]

Tried this but get this:

Sorry, path should be /tmp /syslog.log instead.

 

[blackfireball5]

@RMerlin Re-downloaded the entire 388.1 firmware. Dirty flashed it. Same bootlooping.

Sorry, path should be /tmp /syslog.log instead.

Trying this.

 

[blackfireball5]

Sorry, path should be /tmp /syslog.log instead.

Interesting. The last line before it reboots is this:
Nov 8 01:39:51 crond[2722]: time disparity of 2373214 minutes detected

Nov  8 01:39:49 kernel: tdts: tcp_conn_timeout = 300 sec
Nov  8 01:39:50 wlceventd: wlceventd_proc_event(469): eth10: Deauth_ind 2C:AA:8E:0C:2D:FD, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Nov  8 01:39:50 wlceventd: wlceventd_proc_event(486): eth10: Disassoc 2C:AA:8E:0C:2D:FD, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Nov  8 01:39:50 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd IEEE 802.11: disassociated
Nov  8 01:39:50 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd IEEE 802.11: disassociated
Nov  8 01:39:50 dhcp6_client: WAN Prefix Size Requested:/64, Received:/64
Nov  8 01:39:50 dnsmasq-dhcp[2676]: DHCPv6 stateless on 2600:1700:8150:4cef::, constructed for br0
Nov  8 01:39:50 dnsmasq-dhcp[2676]: router advertisement on 2600:1700:8150:4cef::, constructed for br0
Nov  8 01:39:50 dhcp6_client: bound address 2600:1700:8150:4ce0::49/128, prefix 2600:1700:8150:4cef::/64
Nov  8 01:39:50 dnsmasq-dhcp[2676]: DHCPREQUEST(br0) 192.168.50.134 c8:fd:19:73:17:0b
Nov  8 01:39:50 dnsmasq-dhcp[2676]: DHCPACK(br0) 192.168.50.134 c8:fd:19:73:17:0b gdocntl
Nov  8 01:39:51 kernel: SHN Release Version: 2.0.6 9d6bb506
Nov  8 01:39:51 kernel: UDB Core Version: 0.2.20
Nov  8 01:39:51 kernel: Init chrdev /dev/idpfw with major 191
Nov  8 01:39:51 kernel: Registered DNS Req parsing
Nov  8 01:39:51 kernel: IDPfw: flush fc
Nov  8 01:39:51 kernel: IDPfw: IDPfw is ready
Nov  8 01:39:51 kernel: sizeof forward pkt param = 280
Nov  8 01:39:51 BWDPI: fun bitmap = 47f
Nov  8 01:39:51 crond[2722]: time disparity of 2373214 minutes detected

 

[RMerlin]

@RMerlin Re-downloaded the entire 388.1 firmware. Dirty flashed it. Same bootlooping.




Trying this.

I wonder if your issue may be related to another issue I encountered a few weeks ago on the GT-AXE16000, where enabling AiProtection (or Adaptive QoS) with an iptables rule setting a mark would also cause the router to reboot.

Without enabling AiProtection, can you see if you have any iptables rule that does a --set-mark? Check the output from these commands:

iptables -L -vn
iptables -t nat -L -vn
iptables -t mangle -L -vn

 

[RMerlin]

Interesting. The last line before it reboots is this:

Just a coincidence. That line is right after all the bwdpi-related entries where the Trend Micro engine is getting loaded, which is probably what sets the crashing situation.

 

[blackfireball5]

I wonder if your issue may be related to another issue I encountered a few weeks ago on the GT-AXE16000, where enabling AiProtection (or Adaptive QoS) with an iptables rule setting a mark would also cause the router to reboot.

Without enabling AiProtection, can you see if you have any iptables rule that does a --set-mark? Check the output from these commands:

iptables -L -vn
iptables -t nat -L -vn
iptables -t mangle -L -vn

Not exactly sure what I'm looking for. Here are the results:

iptables -L -vn

iptables -L -vn - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

iptables -t nat -L -vn

iptables -t nat -L -vn - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

iptables -t mangle -L -vn

iptables -t mangle -L -vn - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

P.S. I'm off to bed. Will continue troubleshooting when I can.

Thank you for your help.