ASUS RT-AC68U Firmware version 3.0.0.4.384.45717 [2019/05/13]

[effortless]

Where do I change this? Under Wireless - General, I changed "Control Channel" from Auto to 36 and halved my speed.

You should do a site survey and find the best channel to use. There are some good apps for Android and iOS that will show neighboring Wi-Fi Routers and other devices and the channels they're using. Find the least used/most open ones, the lower channels are a little better because they aren't as prone to slowing down when they detect radar etc.

 

[Grisu]

Where do I change this? Under Wireless - General, I changed "Control Channel" from Auto to 36 and halved my speed.

For US ch. 149+ got much (!!!) more power 1W than ch. 36 with only 200mW, could be the reason.
Other reason could be that your ch. 36 uses only less bandwith, set ch. 36 with 80MHz bandwith.

 

[PlayaSucia]

I'll be upgrading later today and will report back whether it addresses the issue or not.
Actually I was just about to downgrade because of this problem. I had reported the issue using the feedback tool but never got a response but hopefully they are aware of it.

I upgraded to .45717 on the 20th and still have the stability issue discussed at the previous release so I don't think there were any hidden fixes in this release other than the security listed.

I'm going to send another feedback and hope for the next release.

 

[fastoy]

I upgraded to .45717 on the 20th and still have the stability issue discussed at the previous release so I don't think there were any hidden fixes in this release other than the security listed.

I'm a relative novice to routers but I've been following this thread and reading about optimizing the router's wireless config.

I'm running .45717 and have changed my control channel to 157. Prior to changing the control channel I was having several incidents per day of being unable to reach the router and hence the Internet from my Wi-Fi-connected ThinkPad. These periods would last 2 minutes or more. I was also seeing the bandwidth at my ThinkPad drop to single Mbps over several hours. Since changing to 157 I've had 2 missed pings of the router over 48 hours and my bandwidth has stayed at ~180Mbps.

I'm not quite ready to move my wife back to the Asus SSID but I will soon.

It's unlikely that something external to my house has changed as I'm on a 1.5 acre lot. I haven't studied the various firmware releases along the way but I suspect that something has changed in channel management or channel defaults.

 

[Phi Tran]

I upgraded to .45717 on the 20th and still have the stability issue discussed at the previous release so I don't think there were any hidden fixes in this release other than the security listed.

I'm going to send another feedback and hope for the next release.

I too have issue with .45717. I've just gone back to .45708. .45708 seems to work well for me.

 

[bachastain]

Version 3.0.0.4.384.45717 2019/05/13

45717 has been pretty solid for me for the last 2 weeks. Initially, it was causing attach thrashing (repeated and continuous attach failures) of 2 of our Android cellphones of different makes. The log indicated the Roaming Assistant might be the cause so I disabled that and everything has been solid since with Roaming Assistant disabled. With that disabled I sometimes end up with a client attached to the weaker box, but Roaming Assistant created more problems than it solved.

2 ASUS RT-AC66U B1 in a Mesh.

 

[bachastain]

Of course as soon as I posted that, the node acted up. I got the dreaded No Internet at the client. I could ping 192.168.1.1 but not the node 192.168.1.60. The node was acting like it locked up and wouldn't respond to pings. I decided to wait and a few minutes later 60 started responding to pings. I checked the router log and nothing was logged around that time. So after figuring out how to access the node log, it shows these messages. I didn't look at my watch but I think it happened around 12:2x or so.

May 27 12:21:30 rc_service: watchdog 242:notify_rc start_cfgsync
May 27 12:21:59 acsd: scan in progress ...
May 27 12:21:59 acsd: scan in progress ...
May 27 12:22:00 acsd: scan in progress ...
May 27 12:22:00 rc_service: watchdog 242:notify_rc start_cfgsync
May 27 12:22:00 acsd: scan in progress ...
May 27 12:22:00 acsd: scan in progress ...
May 27 12:22:00 acsd: scan in progress ...
May 27 12:22:01 acsd: scan in progress ...
May 27 12:22:01 acsd: scan in progress ...
May 27 12:22:01 acsd: scan in progress ...
May 27 12:22:01 acsd: scan in progress ...
May 27 12:22:02 acsd: scan in progress ...
May 27 12:22:02 acsd: selected channel spec: 0x1804 (2l)
May 27 12:22:02 acsd: Adjusted channel spec: 0x1804 (2l)
May 27 12:22:02 acsd: selected channel spec: 0x1804 (2l)
May 27 12:22:41 rc_service: amas_wlcconnect 10546:notify_rc restart_wireless
May 27 12:22:45 kernel: dpsta enabled
May 27 12:22:46 acsd: scan in progress ...
May 27 12:22:46 acsd: scan in progress ...
May 27 12:22:47 acsd: scan in progress ...
May 27 12:22:47 acsd: scan in progress ...
May 27 12:22:47 acsd: scan in progress ...
May 27 12:22:47 acsd: scan in progress ...
May 27 12:22:48 acsd: scan in progress ...
May 27 12:22:48 acsd: scan in progress ...
May 27 12:22:48 acsd: scan in progress ...
May 27 12:22:48 acsd: scan in progress ...
May 27 12:22:49 acsd: scan in progress ...
May 27 12:22:49 acsd: selected channel spec: 0x1904 (6u)
May 27 12:22:49 acsd: Adjusted channel spec: 0x1904 (6u)
May 27 12:22:49 acsd: selected DFS-exit channel spec: 0x1904 (6u)
May 27 12:22:49 acsd: selected channel spec: 0x1904 (6u)
May 27 12:22:49 acsd: Adjusted channel spec: 0x1904 (6u)
May 27 12:22:49 acsd: selected channel spec: 0x1904 (6u)
May 27 12:22:49 acsd: scan in progress ...
May 27 12:22:49 acsd: scan in progress ...
May 27 12:22:50 acsd: scan in progress ...
May 27 12:22:50 acsd: scan in progress ...
May 27 12:22:50 acsd: scan in progress ...
May 27 12:22:50 acsd: scan in progress ...
May 27 12:22:51 acsd: scan in progress ...
May 27 12:22:51 acsd: scan in progress ...
May 27 12:22:56 acsd: wl0.1: NONACSD channel switching to channel spec: 0x100b (11)
May 27 12:22:56 acsd: wl1.1: NONACSD channel switching to channel spec: 0xe09b (149/80)
May 27 12:23:14 rc_service: udhcpc_lan 7086:notify_rc stop_httpd
May 27 12:23:14 rc_service: udhcpc_lan 7086:notify_rc start_httpd
May 27 12:23:14 rc_service: waitting "stop_httpd" via udhcpc_lan ...
May 27 12:23:15 RT-AC66U_B1: start httpd:80
May 27 12:23:16 rc_service: udhcpc_lan 7086:notify_rc start_dnsmasq
May 27 12:23:16 rc_service: waitting "start_httpd" via udhcpc_lan ...
May 27 12:23:17 LAN: network changes (192.168.1.60/255.255.255.0 --> 192.168.1.60/255.255.255.0)
May 27 12:23:17 rc_service: udhcpc_lan 7086:notify_rc stop_samba
May 27 12:23:17 rc_service: udhcpc_lan 7086:notify_rc start_samba
May 27 12:23:17 rc_service: waitting "stop_samba" via udhcpc_lan ...
May 27 12:23:18 Samba Server: smb daemon is stoped
May 27 12:23:18 kernel: gro disabled
May 27 12:23:18 kernel: gro disabled
May 27 12:37:58 acsd: scan in progress ...
May 27 12:37:58 acsd: scan in progress ...
May 27 12:37:58 acsd: scan in progress ...
May 27 12:37:58 acsd: scan in progress ...
May 27 12:37:59 acsd: scan in progress ...
May 27 12:37:59 acsd: scan in progress ...
May 27 12:37:59 acsd: scan in progress ...
May 27 12:37:59 acsd: scan in progress ...
May 27 12:38:00 acsd: scan in progress ...
May 27 12:38:00 acsd: scan in progress ...
May 27 12:38:00 acsd: scan in progress ...
May 27 12:38:00 acsd: selected channel spec: 0x1805 (3l)
May 27 12:38:00 acsd: Adjusted channel spec: 0x1805 (3l)
May 27 12:38:00 acsd: selected channel spec: 0x1805 (3l)

My guess is the node spontaneously rebooted. That would explain why it didn't respond to pings for a few minutes but eventually came back on it's own (with no clients) without me doing anything.

This is the second RT-AC66U B1 I've had as the node. Both did this. Usually only once every few days. It might be happening more often but comes back by itself without me noticing.

 

[Phi Tran]

That was also my experience. The internet seems to be disconnected for 2-3 minutes, then everything came back normal. I went back to .45708 and the problem went away.

 

[fastoy]

That was also my experience. The internet seems to be disconnected for 2-3 minutes, then everything came back normal. I went back to .45708 and the problem went away.

Try changing your Control Channel [http://router.asus.com/Advanced_Wireless_Content.asp] to a high number. 157 worked for me.

 

[maxbraketorque]

Sure is starting to look like something besides security patches was changed in 45717. Or maybe one of the patches is causing this. I can't tell from the posts whether this is limited to occurring only in AiMesh mode or for all operating modes.

 

[bachastain]

Try changing your Control Channel [http://router.asus.com/Advanced_Wireless_Content.asp] to a high number. 157 worked for me.

Mine was on Auto and channel 149 so I changed it to 157.

 

[PlayaSucia]

I'm a relative novice to routers but I've been following this thread and reading about optimizing the router's wireless config.

I'm running .45717 and have changed my control channel to 157. Prior to changing the control channel I was having several incidents per day of being unable to reach the router and hence the Internet from my Wi-Fi-connected ThinkPad. These periods would last 2 minutes or more. I was also seeing the bandwidth at my ThinkPad drop to single Mbps over several hours. Since changing to 157 I've had 2 missed pings of the router over 48 hours and my bandwidth has stayed at ~180Mbps.

I'm not quite ready to move my wife back to the Asus SSID but I will soon.

It's unlikely that something external to my house has changed as I'm on a 1.5 acre lot. I haven't studied the various firmware releases along the way but I suspect that something has changed in channel management or channel defaults.

Thanks for the suggestion but I've never used Auto and have tried different channels, both high & low band. I've also checked my network with InSSIDer and don't have any competing 5ghz networks; I found the lower band gives me better signal strength by about 3-5 dBm. You can check the signal connection strength and noise in dBm under 'Advance Settings/System Log/Wireless Log' in the admin page.

 

[fastoy]

I did IT problem determination for several Fortune 50 companies for 40 years and I'm stumped. After 3 days with only 2 missed pings, I turned off my ping monitor. In a couple of hours my bandwidth dropped from ~180Mbps to ~40Mbps.

I'm not certain that the absence of loss of Internet (actually LAN as I can't reach the router) connectivity is related to the active ping monitor. I believe that changing the Control Channel mitigated that.

I'm reluctant to fall back prior to .45713 as that level fixed the hanging of the web UI when inquiring of the Traffic Analyzer.

Maybe it's time for Merlin.

 

[bachastain]

Changing to channel 157 didn't help. This time it seemed to break the connection between the router 192.168.1.1 and the node 192.168.1.60 because the client (attached to the node) could ping the node but not the router. Within a couple of minutes the client detached from the node, attached to the router, and all pings started working. Node log shows nothing during that time.

 

[bachastain]

3.0.0.4.384.45717 continues to give problems. This time, the node (still responding to pings) showed only 1 client attached. That client was in fact attached to the router. Trying other clients, no one would attach to the node even though they usually do. I was able to telnet and ping the node, but it didn't seem to be acting like a node. I looked through the node log and there wasn't anything interesting. Nor the router log. In the end I couldn't get the node to act like a node so I telnet rebooted it, which restored node functionality. Clients are once again attaching to the node.

 

[Grisu]

Try M&M reset procedure from L&LD's signature.

 

[bachastain]

Already performed twice when the firmware was loaded.

 

[L&LD]

Already performed twice when the firmware was loaded.

You may need to do it to both the main and all nodes at the same time before setting it up in AiMesh again.

 

[bachastain]

When I installed 45717 I reset the router on one day and did the node on the next day. Later it occurred to me that they might need to be reset at the same time, so that was the second reset. Both boxes were reset at the same time before bringing either online.

I also have a spare RT-AC66U B1 so I rotated the hardware. Router got replaced with the node and node got replaced by the spare (also doing a reset). So 2 different boxes as the router and 2 different boxes as the node.

My setup is currently 1 router and 1 node.

 

[PlayaSucia]

I'm still having the dropping issue with this firmware and I also did a factory reset when I installed it. This issue has existed for the last several releases for me.