ASUS RT-AC68U Firmware version 3.0.0.4.384.45713

[FKYR]

I could further imagine the root cause of the aimesh disconnection problem.

1. AImesh needs all the mesh nodes in the same wifi channel.
2. When two of the nodes' locations are too nearby, they detect each other as noise and change to other channel together.
3. Result, it will change the channel every 15 mins

When I tried in AP mode, router and ap could be separated into different channels, so it did not detect noise nearby

I could not understand why the aimesh needs all nodes in the same channel

 

[Smokindog]

I could further imagine the root cause of the aimesh disconnection problem.

1. AImesh needs all the mesh nodes in the same wifi channel.
2. When two of the nodes' locations are too nearby, they detect each other as noise and change to other channel together.
3. Result, it will change the channel every 15 mins

When I tried in AP mode, router and ap could be separated into different channels, so it did not detect noise nearby

I could not understand why the aimesh needs all nodes in the same channel

I agree it would be nice to allow channel selection.

I discovered quite by accident the other day that if you're using a wired interconnect and have even changed the interconnect from Auto to Ethernet, the system will fall back to a wireless interconnect if the ethernet is unplugged. That's probably why they enforce the same channel settings. I think that's a bug. If you set the interconnect to Auto or Wireless, OK. However, if I tell it I want a wired interconnect, each node should select the best channels for its specific location. If it then loses the Ethernet connection upstrem it should "go to sleep" to allow clients to switch to connected nodes.

And that reminds me of something else I've wanted. If the main node loses contact with any mesh nodes it would be nice to have it send an email and/or a text.

 

[FKYR]

Maybe I can think it in this way.

Just like wifi server side & laptop client side have to be in the same channel. In order to let aimesh nodes communicate with each other over wireless, they have to be in the same channel. That's could explain this behavior.

I agree that it would be much better if ASUS could separate the channel of the nodes when they are connecting over ethernet.

 

[Ronald Schwerer]

By having all nodes on the same channel it makes handoff much more seamless (in theory) for the client. Otherwise the client would have to go hunting for another signal with the same (or another recognized) SSID. Or worse in some environments - a totally different SSID. What you'd have would not be a "mesh" but just a regular router and AP setup.

Its an unfortunate design compromise forced when you don't have a dedicated backhaul (either wired or a separate 5Ghz radio like the higher-end models).

 

[wouterv]

Yesterday with the Android tablet, today with a Windows 10 laptop: wireless stays indicating as connected, no Internet access, router not reachable, after minutes it recover automatically, no messages in the system log.
Downgraded the router from 3.0.0.4.384.45713 to 3.0.0.4.384.45149 (I also don't like the additional system log message caused by 3.0.0.4.384.45708), reverted to factory defaults and configured the router manual.
Let's see if it brings back the router stability.

The downgrade from 3.0.0.4.384.45713 to 3.0.0.4.384.45149 is a week ago, the router proved to be stable again with exact the same pretty straight forward configuration (no AiMesh, no Ai stuff at all).
No more loss of Internet.
There is definitely something wrong in 3.0.0.4.384.45713.

Of course I do see old issues again in 3.0.0.4.384.45149 (broken network map and associate/dis-associate messages in the System Log), and this firmware lacks the latest security fixes, so I prefer to install a good working firmware with all security fixes.

 

[Smokindog]

Maybe I can think it in this way.

Just like wifi server side & laptop client side have to be in the same channel. In order to let aimesh nodes communicate with each other over wireless, they have to be in the same channel. That's could explain this behavior.

I agree that it would be much better if ASUS could separate the channel of the nodes when they are connecting over ethernet.

That's why I said if you select "Ethernet" for the backhaul there should be independent selection of channels. That's a reasonable compromise in my opinion. Right now "Ethernet" just means Preferred because it will drop back to wireless if the Ethernet connection is lost. I can see the list having a 3rd option and/or a sub-menu like Auto(Best Connection), Auto(Ethernet preferred), Auto(Wireless preferred),Wireless(no-fallback), Ethernet(no-fallback).

Is there an ASUS forum the ASUS monitors and takes feedback for features? I've never found one but I seem to miss a lot in my old age

 

[Grisu]

Is there an ASUS forum the ASUS monitors and takes feedback for features? I've never found one but I seem to miss a lot in my old age

no, but there has been vip.asus.com/forum till a year ago, but never seen anyone from Asus there too ...
https://www.snbforums.com/threads/asus-forum-gone.46832/

 

[RMerlin]

Is there an ASUS forum the ASUS monitors and takes feedback for features? I've never found one but I seem to miss a lot in my old age

Use the Feedback page on the router.

 

[Hozz]

I have a RT-AC86U and RT-AC68U working as a mesh network.
Since updating to this latest firmware 5GHz devices seem to disconnect and reconnect frequently and I get the following messages in the system log.
May 4 18:22:46 acsd: selected channel spec: 0xe06a (100/80)
May 4 18:22:46 acsd: Adjusted channel spec: 0xe06a (100/80)
May 4 18:22:46 acsd: selected channel spec: 0xe06a (100/80)
My solution has been to set the 5GHz wireless Control Channel to a specific channel rather than leaving it on Auto.
So far this seems to have resolved the problem.

 

[wouterv]

The downgrade from 3.0.0.4.384.45713 to 3.0.0.4.384.45149 is a week ago, the router proved to be stable again with exact the same pretty straight forward configuration (no AiMesh, no Ai stuff at all).
No more loss of Internet.
There is definitely something wrong in 3.0.0.4.384.45713.

Of course I do see old issues again in 3.0.0.4.384.45149 (broken network map and associate/dis-associate messages in the System Log), and this firmware lacks the latest security fixes, so I prefer to install a good working firmware with all security fixes.

Use the Feedback page on the router.

I tried to send feedback through the router feedback page, my ISP seems not to support it that way.
The router it self suggested to send the feedback to: router_feedback@asus.com
So I did, now I am curious to Asus response.

 

[maxbraketorque]

I tried to send feedback through the router feedback page, my ISP seems not to support it that way.
The router it self suggested to send the feedback to: router_feedback@asus.com
So I did, now I am curious to Asus response.

I've never received a response from ASUS. :-(

 

[RMerlin]

I've never received a response from ASUS. :-(

They typically only follow up for bug reports that require further details. Some people posted on the forums in the past about follow ups they had with them.

 

[follower]

AiMesh WiFi issue.
Nodes: Ethernet Backhaul.

1. Devices can't find the nodes.
2. Devices are connected to nodes but can't connect to the internet even if WiFi shows FULL strength signal.
3. Devices can't switch to other nodes properly. They still hold the nodes that have weak signal.

Tried these but none of them work.

1. NVRAM clear.
2. Restart: works for a while.
3. Power off and on: works for a while.
4. Disable smart connect: works for a while.

Go to H~~~ ASUS.

 

[NetworkDude]

I updated my router to 3.0.0.4.384.45717.

I then rebooted my router and none of the LAN ports work, no lights on any ports. The router cannot be reached. The only lights that are on are power, 2.4ghz, and 5ghz. Although, Wifi doesn't work either. No buttons on the unit work.

The only fix is to put the router into rescue mode (pull power, hold reset 5 seconds, plug in power, power light should blink) and then use the firmware restoration tool to restore firmware 3.0.0.4.384.32799.

Luckily, the router restored successfully and retained all my settings.

If I restore the latest firmware, I get the dead router issue again.

I will try a hard reset and manual setting entry this weekend.

 

[bachastain]

No change in my node outages. Node still continues to periodically glitch, forcing all node clients to flip to the router. Frequency is still once every day or 2. The node becomes unpingable for a 2-3 minutes and all the clients timeout. Pings of the router during the node outage were still good. Nothing in the router log during the outage, but the node log shows the below. Pings started failing at about 12:49.03 (client time):

Jun 5 12:45:57 acsd: scan in progress ...
Jun 5 12:45:57 acsd: scan in progress ...
Jun 5 12:45:58 acsd: scan in progress ...
Jun 5 12:45:58 acsd: selected channel spec: 0x1804 (2l)
Jun 5 12:45:58 acsd: Adjusted channel spec: 0x1804 (2l)
Jun 5 12:45:58 acsd: selected channel spec: 0x1804 (2l)
Jun 5 12:46:28 acsd: wl0.1: NONACSD channel switching to channel spec: 0x100b (11)
Jun 5 12:50:51 rc_service: udhcpc_lan 2800:notify_rc stop_httpd
Jun 5 12:50:51 rc_service: udhcpc_lan 2800:notify_rc start_httpd
Jun 5 12:50:51 rc_service: waitting "stop_httpd" via udhcpc_lan ...
Jun 5 12:50:52 RT-AC66U_B1: start httpd:80
Jun 5 12:50:52 rc_service: udhcpc_lan 2800:notify_rc start_dnsmasq
Jun 5 12:50:52 rc_service: waitting "start_httpd" via udhcpc_lan ...
Jun 5 12:50:53 LAN: network changes (192.168.1.61/255.255.255.0 --> 192.168.1.61/255.255.255.0)
Jun 5 12:50:53 rc_service: udhcpc_lan 2800:notify_rc stop_samba
Jun 5 12:50:53 rc_service: udhcpc_lan 2800:notify_rc start_samba
Jun 5 12:50:53 rc_service: waitting "stop_samba" via udhcpc_lan ...
Jun 5 12:50:54 Samba Server: smb daemon is stoped
Jun 5 12:50:54 kernel: gro disabled
Jun 5 12:50:54 kernel: gro disabled

Pings of the node were back to running about 12:50:53. It seems to have come back much too fast for a spontaneous reboot, so it recovered whatever was wrong within about 2 minutes. The "LAN: network changes" seems interesting considering nothing actually changed. There's a bunch of httpd messages but the node's web pages were never accessed by a client. Not sure what udhcpc_lan is.

 

[PlayaSucia]

Unfortunately 45717 has had no improvement for this random logless drop/auto reconnect issue. And the last few days it has been been dropping like a bastard for me, more-so than usual. I'll probably try factory resetting it again if it keeps up.

Does anyone know what firmware this issue became existent? Worse come to worse I'll downgrading until it gets sorted.

 

[wouterv]

Unfortunately 45717 has had no improvement for this random logless drop/auto reconnect issue. And the last few days it has been been dropping like a bastard for me, more-so than usual. I'll probably try factory resetting it again if it keeps up.

Does anyone know what firmware this issue became existent? Worse come to worse I'll downgrading until it gets sorted.

Read here:
https://www.snbforums.com/threads/a...on-3-0-0-4-384-45713.56052/page-3#post-487462
After the upgrade to 45717 my router seems stable.

 

[bachastain]

Happened again. 2 RT-AC66U B1 running 45713 running as router and mesh node. Both factory reset. The client lost internet for a few minutes for no obvious reason. The router log shows nothing, but the mesh node has:

Jun 19 07:17:20 acsd: scan in progress ...
Jun 19 07:17:20 acsd: scan in progress ...
Jun 19 07:17:20 acsd: scan in progress ...
Jun 19 07:17:20 acsd: scan in progress ...
Jun 19 08:17:23 rc_service: watchdog 241:notify_rc start_cfgsync
Jun 19 08:17:53 rc_service: watchdog 241:notify_rc start_cfgsync
Jun 19 08:46:13 rc_service: udhcpc_lan 14909:notify_rc stop_httpd
Jun 19 08:46:13 rc_service: udhcpc_lan 14909:notify_rc start_httpd
Jun 19 08:46:13 rc_service: waitting "stop_httpd" via udhcpc_lan ...
Jun 19 08:46:14 RT-AC66U_B1: start httpd:80
Jun 19 08:46:14 rc_service: udhcpc_lan 14909:notify_rc start_dnsmasq
Jun 19 08:46:14 rc_service: waitting "start_httpd" via udhcpc_lan ...
Jun 19 08:46:16 LAN: network changes (192.168.1.60/255.255.255.0 --> 192.168.1.60/255.255.255.0)
Jun 19 08:46:16 rc_service: udhcpc_lan 14909:notify_rc stop_samba
Jun 19 08:46:16 rc_service: udhcpc_lan 14909:notify_rc start_samba
Jun 19 08:46:16 rc_service: waitting "stop_samba" via udhcpc_lan ...
Jun 19 08:46:17 Samba Server: smb daemon is stoped
Jun 19 08:46:17 kernel: gro disabled
Jun 19 08:46:17 kernel: gro disabled
Jun 19 08:59:20 acsd: scan in progress ...
Jun 19 08:59:20 acsd: scan in progress ...
Jun 19 08:59:20 acsd: scan in progress ...
Jun 19 08:59:20 acsd: scan in progress ...

When this happens all clients using the mesh node get kicked off and flip to the router. Anyone know what event these log messages indicate happened?

Update: Happened again. Only got the first line this time:

Jun 19 16:51:21 acsd: scan in progress ...
Jun 19 16:51:21 acsd: scan in progress ...
Jun 19 16:51:21 acsd: scan in progress ...
Jun 19 17:10:53 rc_service: watchdog 241:notify_rc start_cfgsync

So whatever cfgsync is doing seems to coincide with the client drops on the node.

Update: Still happening. All node clients dropped at 18:19

Jun 24 18:19:25 rc_service: watchdog 244:notify_rc start_cfgsync

 

[hancox]

Happened again. 2 RT-AC66U B1 running 45713 running as router and mesh node. Both factory reset. The client lost internet for a few minutes for no obvious reason. The router log shows nothing, but the mesh node has:

Jun 19 07:17:20 acsd: scan in progress ...
Jun 19 07:17:20 acsd: scan in progress ...
Jun 19 07:17:20 acsd: scan in progress ...
Jun 19 07:17:20 acsd: scan in progress ...
Jun 19 08:17:23 rc_service: watchdog 241:notify_rc start_cfgsync
Jun 19 08:17:53 rc_service: watchdog 241:notify_rc start_cfgsync
Jun 19 08:46:13 rc_service: udhcpc_lan 14909:notify_rc stop_httpd
Jun 19 08:46:13 rc_service: udhcpc_lan 14909:notify_rc start_httpd
Jun 19 08:46:13 rc_service: waitting "stop_httpd" via udhcpc_lan ...
Jun 19 08:46:14 RT-AC66U_B1: start httpd:80
Jun 19 08:46:14 rc_service: udhcpc_lan 14909:notify_rc start_dnsmasq
Jun 19 08:46:14 rc_service: waitting "start_httpd" via udhcpc_lan ...
Jun 19 08:46:16 LAN: network changes (192.168.1.60/255.255.255.0 --> 192.168.1.60/255.255.255.0)
Jun 19 08:46:16 rc_service: udhcpc_lan 14909:notify_rc stop_samba
Jun 19 08:46:16 rc_service: udhcpc_lan 14909:notify_rc start_samba
Jun 19 08:46:16 rc_service: waitting "stop_samba" via udhcpc_lan ...
Jun 19 08:46:17 Samba Server: smb daemon is stoped
Jun 19 08:46:17 kernel: gro disabled
Jun 19 08:46:17 kernel: gro disabled
Jun 19 08:59:20 acsd: scan in progress ...
Jun 19 08:59:20 acsd: scan in progress ...
Jun 19 08:59:20 acsd: scan in progress ...
Jun 19 08:59:20 acsd: scan in progress ...

When this happens all clients using the mesh node get kicked off and flip to the router. Anyone know what event these log messages indicate happened?

Update: Happened again. Only got the first line this time:

Jun 19 16:51:21 acsd: scan in progress ...
Jun 19 16:51:21 acsd: scan in progress ...
Jun 19 16:51:21 acsd: scan in progress ...
Jun 19 17:10:53 rc_service: watchdog 241:notify_rc start_cfgsync

So whatever cfgsync is doing seems to coincide with the client drops on the node.

Are you running "Auto" wireless channel, by any chance?

 

[Smokindog]

Sorry if I missed this in the thread but are the nodes connected by wire or CAN THEY be connected by wire? AiMesh forces all nodes to use the same channels. That can cause a LOT of issues IMO. I understand why they made such a choice but they could add some simple features to mitigate the need.

IF you can wire the nodes together switch to a router and an AP. You'll find numerous threads/recommendations for baseline settings. If you still have issues try downloading a tool like WiFi Analyzer and do manual channel assignments.

Again, sorry if I missed this information in this thread.

PS - I noticed an update for my one AC66 this AM if you're running stock firmware.
Firmware Version:3.0.0.4.382_51640