RT-AC68U - 384.14_2 - AndroidTVs not connecting to wifi on start

[jahkaz]

Hello,

I recently upgraded from 384.13_0 to 384.14_2, and since then i have an issue with all my Android TVs not connecting to the wireless network when they boot up. The only way i can solve this is by getting into the TV menu and manually connect them. Then it works fine until the next power cycle.
Windows laptops don't seem to be affected.

Whenever that happens, i see the following in the system log:

Jan 28 13:21:07 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Jan 28 13:21:07 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Jan 28 13:21:07 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Jan 28 13:21:15 syslog: WLCEVENTD wlceventd_proc_event(386): eth2: Deauth_ind XX:XX:XX:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jan 28 13:21:36 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Jan 28 13:21:36 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Jan 28 13:21:44 syslog: WLCEVENTD wlceventd_proc_event(386): eth2: Deauth_ind XX:XX:XX:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

I did perform a restore to factory defaults but hasn't solved the issue.
Has anyone else encountered this issue in 384.14_2? Maybe a suggestion on how to fix it? It's relatively annoying having to manually connect the TVs to the network every time.

Please note that 384.13_0 or previous versions did not have this issue. I'll probably revert back to that.

Thanks in advance!

 

[martinr]

Welcome to the forum.

You said you reset the router to factory default settings. Can you confirm how you restored your personal settings afterwards; did you manually input all your settings or did you restore them from a backup file?

 

[jahkaz]

Welcome to the forum.

You said you reset the router to factory default settings. Can you confirm how you restored your personal settings afterwards; did you manually input all your settings or did you restore them from a backup file?

Unfortunately i did not restore them from file, i usually do everything manually when i upgrade a "semi-major" version. Should i have restored them from a file?

 

[jahkaz]

Ok...so....I think there is an issue in 384.14_2... - i just did a flashback to 384.13_0 (no factory reset, just basic flashback) and the issue went away, my TVs connect perfectly on startup now.

This is the log:

Jan 28 18:54:59 avahi-daemon[1012]: Loading new alias name RT-AC68U.
Jan 28 18:54:59 avahi-daemon[1012]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Jan 28 18:54:59 avahi-daemon[1012]: New relevant interface br0.IPv4 for mDNS.
Jan 28 18:54:59 avahi-daemon[1012]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Jan 28 18:54:59 avahi-daemon[1012]: New relevant interface lo.IPv4 for mDNS.
Jan 28 18:54:59 avahi-daemon[1012]: Network interface enumeration completed.
Jan 28 18:54:59 avahi-daemon[1012]: Registering new address record for 192.168.1.1 on br0.IPv4.
Jan 28 18:54:59 avahi-daemon[1012]: Registering new address record for 127.0.1.1 on lo.IPv4.
Jan 28 18:54:59 avahi-daemon[1012]: Registering new address record for 127.0.0.1 on lo.IPv4.
Jan 28 18:54:59 Samba_Server: daemon is started
Jan 28 18:54:59 miniupnpd[1023]: HTTP listening on port 38694
Jan 28 18:54:59 miniupnpd[1023]: Listening for NAT-PMP/PCP traffic on port 5351
Jan 28 18:54:59 wsdd2[1024]: starting.
Jan 28 18:54:59 avahi-daemon[1012]: Server startup complete. Host name is RT-AC68U-1920.local. Local service cookie is 1512652112.
Jan 28 18:54:59 avahi-daemon[1012]: Alias name "RT-AC68U" successfully established.
Jan 28 18:55:11 crond[238]: time disparity of 912290 minutes detected
Jan 28 19:04:30 WLCEVENTD: eth2: Assoc XX:XX:XX:XX:XX:XX
Jan 28 19:05:28 WLCEVENTD: eth2: Assoc XX:XX:XX:XX:XX:XX
Jan 28 19:07:45 WLCEVENTD: eth2: Assoc XX:XX:XX:XX:XX:XX
Jan 28 19:09:18 acsd: scan in progress ...
Jan 28 19:09:19 acsd: scan in progress ...

The TV doesn't get disconnected after connecting anymore, everything works fine.

Anyone got any ideas why that happens in 384.14_2?
Has anything major changed on the wireless side of things? Visually it doesn't look like it to me, but...

 

[martinr]

Unfortunately i did not restore them from file, i usually do everything manually when i upgrade a "semi-major" version. Should i have restored them from a file?

No, you did it correctly: if there had been some glitch in your settings, by restoring from a backup file you would have negated the good of the factory reset by importing the glitch back in. By manually inputting your settings you started with a clean sheet.