What's new

RT-AC68U constant disconnects in AiMesh environment

  • 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!

ManfredH

Occasional Visitor
Hello!

I'm getting a little desparate. Since I changed some things in my network environment I can't seem to get a stable WiFi connection. Following setup:
  • Cable box by ISP - all routing/wifi functions deactivated, it only provides cable internet via LAN ports
  • RT-AC68U_white (Asuswrt-Merlin 384.15) connected via LAN to cable box, AiMesh router
  • RT-AC68U_black (Stock FW 3.0.0.4.385_20252-ga052d4c) connected as AiMesh node
  • DSL-AC68U (Asuswrt-Merlin 384.15) connect via 5ghz in bridge mode (bought used but I wasn't aware, that it has no AiMesh support)
Now I am getting regular disconnects from the WiFi. I haven't tested direct LAN connections from AC68U_white, because no important devices are connected there. However I see it on my smartphone, my notebook (connected via LAN to AC68U_black) and my PC (connected via LAN to DSL-AC68U), that the devices lose connectivity several times a day for about 2-5 minutes. I'm guessing, that it's a WiFi reconnect because nothing is reachable, not even internal IPs.

I tried googling the last entries of the log, when this is happening and found some tips for WiFi settings (like beamforming) but nothing helped. Maybe someone sees something in the lates log (created with debug log level).

Log (disconnect at around 11:54):
Code:
Feb 24 11:49:27 dnsmasq-dhcp[229]: DHCPACK(br0) 192.168.42.91 b0:68:e6:3d:6c:10 brother
Feb 24 11:50:16 dnsmasq-dhcp[229]: DHCPDISCOVER(br0) ac:9b:0a:c3:15:26
Feb 24 11:50:16 dnsmasq-dhcp[229]: DHCPOFFER(br0) 192.168.42.253 ac:9b:0a:c3:15:26
Feb 24 11:50:16 dnsmasq-dhcp[229]: DHCPREQUEST(br0) 192.168.42.253 ac:9b:0a:c3:15:26
Feb 24 11:50:16 dnsmasq-dhcp[229]: DHCPACK(br0) 192.168.42.253 ac:9b:0a:c3:15:26 android-6f1089c6216c987f
Feb 24 11:52:36 syslogd exiting
Feb 24 11:52:37 syslogd started: BusyBox v1.25.1
Feb 24 11:52:37 kernel: klogd started: BusyBox v1.25.1 (2020-02-08 13:38:20 EST)
Feb 24 11:54:39 dnsmasq-dhcp[229]: DHCPREQUEST(br0) 192.168.42.252 68:a8:6d:6f:42:97
Feb 24 11:54:39 dnsmasq-dhcp[229]: DHCPACK(br0) 192.168.42.252 68:a8:6d:6f:42:97 podPhone
Feb 24 11:55:21 dnsmasq-dhcp[229]: DHCPDISCOVER(br0) ac:9b:0a:c3:15:26
Feb 24 11:55:21 dnsmasq-dhcp[229]: DHCPOFFER(br0) 192.168.42.253 ac:9b:0a:c3:15:26
Feb 24 11:55:21 dnsmasq-dhcp[229]: DHCPREQUEST(br0) 192.168.42.253 ac:9b:0a:c3:15:26
Feb 24 11:55:21 dnsmasq-dhcp[229]: DHCPACK(br0) 192.168.42.253 ac:9b:0a:c3:15:26 android-6f1089c6216c987f
Feb 24 11:56:35 syslog: WLCEVENTD wlceventd_proc_event(430): eth1: ReAssoc 88:A9:B7:62:25:E1, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:36 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 34:D2:70:D3:61:DB, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:36 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 34:D2:70:D3:61:DB, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:36 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 1C:C1:DE:C7:BC:89, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:37 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth B0:68:E6:3D:6C:10, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:37 syslog: WLCEVENTD wlceventd_proc_event(430): eth1: ReAssoc B0:68:E6:3D:6C:10, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:48 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 1C:C1:DE:C7:BC:89, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:51 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 1C:C1:DE:C7:BC:89, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:51 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 1C:C1:DE:C7:BC:89, status: 0, reason: d11 RC reserved (0)
Feb 24 11:56:54 dnsmasq-dhcp[229]: DHCPDISCOVER(br0) 192.168.42.90 1c:c1:de:c7:bc:89
Feb 24 11:56:54 dnsmasq-dhcp[229]: DHCPOFFER(br0) 192.168.42.90 1c:c1:de:c7:bc:89
Feb 24 11:56:54 dnsmasq-dhcp[229]: DHCPREQUEST(br0) 192.168.42.90 1c:c1:de:c7:bc:89
Feb 24 11:56:54 dnsmasq-dhcp[229]: DHCPACK(br0) 192.168.42.90 1c:c1:de:c7:bc:89 HPLaserjet
Feb 24 11:57:38 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 30:5A:3A:C6:C8:69, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 24 11:57:39 syslog: WLCEVENTD wlceventd_proc_event(401): eth2: Disassoc 30:5A:3A:C6:C8:6C, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 24 11:57:42 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 30:5A:3A:C6:C8:69, status: 0, reason: d11 RC reserved (0)
Feb 24 11:57:42 kernel: br0: port 4(wds0.1) entering forwarding state
Feb 24 11:57:42 kernel: device wds0.1 left promiscuous mode
Feb 24 11:57:42 kernel: br0: port 4(wds0.1) entering disabled state
Feb 24 11:57:43 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 30:5A:3A:C6:C8:69, status: 0, reason: d11 RC reserved (0)
Feb 24 11:57:43 kernel: device wds0.1 entered promiscuous mode
Feb 24 11:57:43 kernel: br0: topology change detected, propagating
Feb 24 11:57:43 kernel: br0: port 4(wds0.1) entering forwarding state
Feb 24 11:57:43 kernel: br0: port 4(wds0.1) entering forwarding state
Feb 24 11:57:44 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth 30:5A:3A:C6:C8:6C, status: 0, reason: d11 RC reserved (0)
Feb 24 11:57:44 kernel: br0: port 5(wds1.1) entering forwarding state
Feb 24 11:57:44 kernel: device wds1.1 left promiscuous mode
Feb 24 11:57:44 kernel: br0: port 5(wds1.1) entering disabled state
Feb 24 11:57:44 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc 30:5A:3A:C6:C8:6C, status: 0, reason: d11 RC reserved (0)
Feb 24 11:57:44 kernel: device wds1.1 entered promiscuous mode
Feb 24 11:57:44 kernel: br0: topology change detected, propagating
Feb 24 11:57:44 kernel: br0: port 5(wds1.1) entering forwarding state
Feb 24 11:57:44 kernel: br0: port 5(wds1.1) entering forwarding state
Feb 24 11:57:54 dnsmasq-dhcp[229]: DHCPDISCOVER(br0) 192.168.42.137 30:5a:3a:c6:c8:68
Feb 24 11:57:54 dnsmasq-dhcp[229]: DHCPOFFER(br0) 192.168.42.137 30:5a:3a:c6:c8:68
Feb 24 11:57:54 dnsmasq-dhcp[229]: DHCPREQUEST(br0) 192.168.42.137 30:5a:3a:c6:c8:68
Feb 24 11:57:54 dnsmasq-dhcp[229]: DHCPACK(br0) 192.168.42.137 30:5a:3a:c6:c8:68

WiFi settings on the AiMesh router:
upload_2020-2-24_12-23-42.png

upload_2020-2-24_12-23-8.png
 
First I would switch to Merlin for all routers, and GNUton's Merlin fork for DSL-AC68U as this isnt meant to run RT-firmware!
 
What did you change for it to become unstable?

After doing what @Grisu mentioned, try doing the following:
- Set the wifi channel bandwidth to a fixed bandwidth.
- Set the wifi control channel to a fixed channel.
- Activate Roaming Assistant for both 2.4 Ghz and 5 Ghz in order for Wifi-clients to roam properly.
 
Thank you already for the first hints! The change was, that the AiMesh node was moved from cellar to 2nd floor and the DSL-AC68U was bought and installed as bridge in the cellar. Doing that I updated/reseted all firmwares but didn't log, which firmwares were in use beforehand (but could only have been a couple of months old).

The DSL router has some strange problem with flashing because official and GNUton firmwares cannot be flashed - they are identified as incomatible when trying to upload. I'll try with router recovery mode later.
RTAC68U_black, the AIMesh node, is now also patched to Merlin.

I now set your settings, Salles (channel 6 and 44 have low noise here and were already set before; now additionaly trying 20 MHz for 2.4GHz and 80 MHz for 5GHz). Thanks to your hint I also set the screenshotted WiFi "professional" settings for both bands - didn't see before, that I had to set them individually per band. Maybe this already helps...
 
Should just work with the default settings, yes? Some ad-hoc comments:

o Start with all routers factory default reset. The 68U node can run stock Asuswrt firmware according to Merlin.

o Confirm the router install is fully working before adding the 68U node. Use separate SSIDs and fixed channels (such as 11, 20MHz; and 149+, 80MHz). Leave Roaming Assistant enabled. Disable Airtime Fairness.

o Confirm the 68U node is fully working before adding the used 68U bridge.

o Inspect any wired backhaul cables. Identify wireless backhauls by MAC listed in the router Wireless Log... ideally these should rate -68 dBm or stronger.

o Confirm all antennas are tight.

o Connect a PC to the node WLAN and while running a speedtest, observe its Windows wireless connection status... it should have a steady link rate speed respective of the WiFi protocol and number of antenna streams... a stable 2x2 AC connection should sit at 866 MBps. Repeat after you add the bridge in the cellar.

OE
 
Use restauration tool from Asus to flash GNUton or original stock to your DSL.
Maybe sometimes in the past somebody flashed wrong RT firmware on it and now you got the problem.
What does it show on top in GUI, RT or DSL? If RT then you may have to mod CFE to get it back.
 
The device still says DSL:
upload_2020-2-26_10-49-16.png


Since Monday I haven't noticed any disconnects. I will try today with some extensive copy jobs to/from my NAS but maybe the settings already did the trick.
I remember, that I tried a while with the FW restoration tool but had no luck and ended up patching the RT Merlin firmware (I had read, that for other people it worked but disabled DSL functions - which I don't need).
 
The name DSL-AC68U means that you didnt change cfe (bootloader values).
But 384.15 is definitely RT-firmware from Merlin and not GNUtons compatible firmware!!!

I know you could load RT firmware to this router with miniweb or restauration tool, but there are some incompatibility issues you will have and they wont be if you load correct GNUtons firmware for DSL-routers.
 
Unfortunately the first impression was too good - I again had noticeable disconnects in the last week. So now I'm trying to go step by step and see if I can get GNUton on the DSL device.
The main RT AC68u is already reinstalled, but I'm not sure if I understand the instructions about checking the backhauls correctly? Testing the speed and checking the wireless logs seems good to me though:

Code:
SSID: "Verbindung trennen"
RSSI: 0 dBm    SNR: 0 dB    noise: -92 dBm    Channel: 6
BSSID: 70:8B:CD:30:xx    Capability: ESS ShortSlot
Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
VHT Capable:
    Chanspec: 2.4GHz channel 6 20MHz (0x1006)
    Primary channel: 6
    HT Capabilities:
    Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ]
    VHT Capabilities:
    Supported VHT (tx) Rates:
        NSS: 1 MCS: 0-9
        NSS: 2 MCS: 0-9
        NSS: 3 MCS: 0-9
    Supported VHT (rx) Rates:
        NSS: 1 MCS: 0-9
        NSS: 2 MCS: 0-9
        NSS: 3 MCS: 0-9

Interference Level: Acceptable
Mode    : AP Only

Stations List                          
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC Tx rate Rx rate Connect Time
    30:5A:3A:xx Yes        Yes         -60dBm ac  No  Yes Yes     260M    234M 00:01:07
    B0:4E:26:xx Yes        Yes         -62dBm n   No  Yes Yes      26M   72.2M 00:10:15
    1C:C1:DE:xx Yes        Yes         -53dBm g   No  No  No        1M     54M 00:10:18
    7C:49:EB:xx Yes        Yes         -47dBm n   No  Yes Yes    72.2M     65M 00:10:21
    B0:4E:26:xx Yes        Yes         -46dBm n   No  Yes Yes       1M      1M 00:10:27
    88:A9:B7:xx Yes        Yes         -53dBm n   Yes Yes No    144.4M      1M 00:10:30
    B0:4E:26:xx Yes        Yes         -68dBm n   No  Yes Yes    58.5M   72.2M 00:10:30
    B0:68:E6:xx Yes        Yes         -68dBm n   Yes Yes No        1M     24M 00:10:31
    34:D2:70:xx Yes        Yes         -55dBm n   No  Yes Yes       1M  144.4M 00:10:34
    FC:65:DE:xx Yes        Yes         -58dBm n   No  Yes Yes    72.2M     24M 00:10:34
    68:37:E9:xx Yes        Yes         -32dBm n   No  Yes Yes    72.2M     24M 00:10:34

SSID: "Disconnect"
RSSI: 0 dBm    SNR: 0 dB    noise: -92 dBm    Channel: 44/80
BSSID: 70:8B:CD:30:xx    Capability: ESS
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
VHT Capable:
    Chanspec: 5GHz channel 42 80MHz (0xe22a)
    Primary channel: 44
    HT Capabilities:
    Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ]
    VHT Capabilities:
    Supported VHT (tx) Rates:
        NSS: 1 MCS: 0-9
        NSS: 2 MCS: 0-9
        NSS: 3 MCS: 0-9
    Supported VHT (rx) Rates:
        NSS: 1 MCS: 0-9
        NSS: 2 MCS: 0-9
        NSS: 3 MCS: 0-9

Interference Level: Acceptable
Mode    : AP Only

DFS status: state IDLE time elapsed 150ms radar channel cleared by DFS none

Channel Information                    
----------------------------------------
Channel 36    A Band
Channel 40    A Band
Channel 44    A Band
Channel 48    A Band
Channel 52    A Band, RADAR Sensitive, Passive
Channel 56    A Band, RADAR Sensitive, Passive
Channel 60    A Band, RADAR Sensitive, Passive
Channel 64    A Band, RADAR Sensitive, Passive
Channel 100    A Band, RADAR Sensitive, Passive
Channel 104    A Band, RADAR Sensitive, Passive
Channel 108    A Band, RADAR Sensitive, Passive
Channel 112    A Band, RADAR Sensitive, Passive
Channel 116    A Band, RADAR Sensitive, Passive
Channel 132    A Band, RADAR Sensitive, Passive
Channel 136    A Band, RADAR Sensitive, Passive
Channel 140    A Band, RADAR Sensitive, Passive

Stations List                          
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC Tx rate Rx rate Connect Time
    30:5A:3A:xx Yes        Yes         -69dBm ac  No  Yes Yes     702M    351M 00:01:00
    44:85:00:xx Yes        Yes         -42dBm ac  Yes Yes Yes   866.7M      6M 00:02:29
 
Last edited:
Managed to flash GNUton now - I always tried with the FW restauration tool which couldn‘t find the DSL router. Putting the device into recovery mode, configuring my notebook LAN IP as described on the restauration support page and simply browsing to 192.168.1.1 (CFE miniWeb Server) did the trick!

However I‘m now missing the general router configuration (usually found under Administration). Is it possible to configure the router as media bridge or AiMesh node over Wifi with this firmware?
 
You wont find such settings, they dont exist on none of their routers!
I said factory and then EVERYTHING is done on MASTER-router.
Soll ichs dir auf deutsch schreiben?
 
Last edited:
*facepalm* I was so fixated on that welcome setup which usually comes on other routers (RT AC68U) after reseting to factory defaults. The assistant lets you select the operation mode (AP, mesh router, mesh node, media bridge) and obviously doesn’t really change anything when you select mesh node mode.
Only after your post I checked the FAQ again, where a simple reset without the need to even login makes a router ready to be found as mesh node...
so, getting on with setting up everything and periodically checking for wifi stability
 
Alright, so after some weeks of trial and error with different combinations I guess my combination of devices just can't handle AI Mesh - at least without LAN backhaul. Because whenever I add just one mesh node, the connection seems good but there are a couple of times during the day when the node loses connection and of course the connected devices have a short disconnect too. Now I'm using one RT-AC68u as Media Bridge which connects to the 5GHz Wifi and by slightly repositioning the main router there's a stable connection everywhere I need. Plans are to lay a cable between the floors, maybe I'll try AI Mesh again then with a wired backhaul.
 
hey Manfred, I've been having the same issues with my 68U as a mesh node. I read somewhere that it runs hot and needs to be underclocked just a little bit. I'll try reading more to see if I can remember what that was all about

More to follow
 
Hi Jason,
ahh, that sounds very plausible... do you use wireless only as well or do you have a wired backhaul?

Anyway I just tried that with one of the devices:
  1. Made sure (i.e. flashed the devices) that the AiMesh router and node both have Merlin firmware
  2. Set Administration\Service-Enable SSH on the router because the node is not directly accessible and the setting is replicated to the node
  3. Connected to the node via putty, checked nvram clkfrequency (command nvram show | grep clk - original setting: 800,666)
  4. Enabled JFFS scripts with nvram set jffs2_scripts="1" and nvram commit (as mentioned in this post)
  5. Changed to directory /jffs/scripts and created a script (according to this post) + made it executable with frequencies of 700,666
  6. Rebooted the node and checked, that clkfreq was still set to the new values - unfortunately not?
I tried to set and commit the frequency manually for now, without reboot. Will check if something needs to be done to keep the values after a reboot and observe the situation for now...
 
i found that underclocking cpu on my rt-68U allow a better speed on aimesh and no more disconnection issue , you can try using telnet on ip of your aimesh node and then use
nvram get clkfreq
on mine it show 800,600
i reduce to 600,600
nvram set asuscfeclkfreq=600,600 && nvram set asuscfecommit=1
nvram set clkfreq=600,600
nvram commit && reboot
wait for reboot, reconnect using telnet
take a look at new clkfreq using
nvram get clkfreq
it shall reflect change and test your network speed after (speedtest using any browser for example)
 

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