RT-AC68U Repeater Problems since 386.*

[Evil Hubie]

I've been running two RT-AC68U routers together, one running wirelessly in repeater mode with separate SSID.

Unfortunately, since I updated to the 386.* versions, I've been having issues when I'm connected to the repeater. Multiple times a day, I'll lose the connection to the gateway and the internet. I'm still connected to the repeater, but I can't ping 192.168.1.1 or access anything beyond that.

These lost connections seem to occur for anywhere from around 10 seconds to a few minutes. They *seem* to go away if I disconnect and reconnect to the repeater.

Any ideas? Thanks in advance.

 

[KGB7]

Re-flash both routers using Rescue Mode.
Afterwords set them up as new. Set second router as Repeater and see if your issue has been resolved.
But first, redownload the firmware, incase the first time your download it was corrupted.

 

[Ronald Schwerer]

I had a similar problem trying both Merlin 386.1_2 and 386.x ASUS ASUSWRT. I also noticed that the repeater's GUI said the Security Level was "Open System". That alone caused me to go back to Merlin 384.19. And before I also get the above suggestion, I did check CRC checks (SHA-256) before installing. Also did a factory reset and reconfigured.

BTW, is your repeater connecting to a Guest SSID on the main router? This also caused problems causing me to go back to 384.19 on all my stuff (RT-AX3000, 68U Node, 38U Repeater). Luckily I made settings & jffs backups on the repeater and router before updating to 386.

 

[Evil Hubie]

The repeater's Security Level is WPA2-Personal. It's connected to the primary 2.4 Ghz SSID (not the guest) on the main router.

I've done nuclear resets and reloaded 386.1_2 on both routers but still encounter frequent disconnects. These seem to be coincident with the following in the repeater system log:

Mar 5 11:00:15 syslog: wlceventd_proc_event(490): eth1: Deauth_ind 14D:A9:87:44:40, status: 0, reason: Group key update timeout (10), rssi:-49
Mar 5 11:00:16 rc_service: psta_monitor 32524:notify_rc restart_wlcmode 0
Mar 5 11:00:16 FTP_Server: daemon is stopped
Mar 5 11:00:16 syslog: wlceventd_proc_event(526): wl0.1: Auth 24A:9B:19:FD:EA, status: Successful (0), rssi:0
Mar 5 11:00:16 syslog: wlceventd_proc_event(555): wl0.1: Assoc 24A:9B:19:FD:EA, status: Successful (0), rssi:0
Mar 5 11:00:16 Samba_Server: smb daemon is stopped
Mar 5 11:00:16 kernel: gro disabled
Mar 5 11:00:18 kernel: dpsta_register: null dpsta_ifnames!
Mar 5 11:00:18 avahi-daemon[557]: Interface br0.IPv4 no longer relevant for mDNS.
Mar 5 11:00:18 avahi-daemon[557]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.221.
Mar 5 11:00:18 avahi-daemon[557]: Withdrawing address record for 192.168.1.221 on br0.
Mar 5 11:00:18 kernel: br0: port 4(wl0.1) entering forwarding state
Mar 5 11:00:18 kernel: br0: port 3(eth2) entering forwarding state
Mar 5 11:00:18 kernel: br0: port 2(eth1) entering forwarding state
Mar 5 11:00:18 kernel: br0: port 1(vlan1) entering forwarding state
Mar 5 11:00:19 avahi-daemon[557]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.221.
Mar 5 11:00:19 avahi-daemon[557]: New relevant interface br0.IPv4 for mDNS.
Mar 5 11:00:19 avahi-daemon[557]: Registering new address record for 192.168.1.221 on br0.IPv4.
Mar 5 11:00:19 avahi-daemon[557]: Withdrawing address record for 192.168.1.221 on br0.
Mar 5 11:00:19 avahi-daemon[557]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.221.
Mar 5 11:00:19 avahi-daemon[557]: Interface br0.IPv4 no longer relevant for mDNS.
Mar 5 11:00:19 kernel: br0: port 4(wl0.1) entering forwarding state
Mar 5 11:00:19 kernel: br0: port 4(wl0.1) entering forwarding state
[etc.]

The deauth_ind is with the main router, and I haven't figured out what the group key update timeout is all about. Any ideas?

 

[noah way]

I had the same problem with 386.1 on the 68U - random disconnects without any errors in the log on either the repeater or the base station. I did a factory reset on the repeater multiple times with no change.

The condition was exacerbated by running ExpressVPN on a pc, which caused an almost immediate disconnect or a guaranteed disconnect when turning off the VPN.

A couple of other routers (66U and 66U B1) worked fine but had less signal strength.

After installing the latest Asus FW (3.0.0.4.386_41634-g08f88a) everything seems stable.

 

[Evil Hubie]

I replaced the RT-AC68U router with an RT-AX86U, and upgraded both the RT-AX86U and the RT-AC68U repeater to the latest ASUS firmware. So far no disconnect problems.

 

[noah way]

I had the same problem with 386.1 on the 68U - random disconnects without any errors in the log on either the repeater or the base station. I did a factory reset on the repeater multiple times with no change.

The condition was exacerbated by running ExpressVPN on a pc, which caused an almost immediate disconnect or a guaranteed disconnect when turning off the VPN.

A couple of other routers (66U and 66U B1) worked fine but had less signal strength.

After installing the latest Asus FW (3.0.0.4.386_41634-g08f88a) everything seems stable.

UPDATE. This looks like a hardware problem as problems continue with the stock firmware. RMAing the unit.

Should have given it some more time before jumping to conclusion that AsusMerlin FW was an issue. Apologies ---

 

[ldeveraux]

I have recently GUI upgraded my repeaters from 384.19 to 386.1_2 on my AC68P. The Security Level on the Network Map page has changed from WPA2-Personal to Open System, although when I check the wireless status the WPA password is still there. I also don't see any open APs on my network. I've since completely reset the router and setup again with the same issue. Is this a visual bug or have I somehow disabled WPA2?! Strangely, upgrading my AP which is a AC68U has no change in the security level..

 

[Calkulin]

With the AC68U setup in AiMesh on 386, using Guest Network 1 and setting Sync to AiMesh Node to All with cause crazy ping drops when connected to the node on 3 different setups I manage. Setting it to Router Only resolves it though or using Guest Network 2 will also since that setting is not available there,