Bad router or bad phone?

[Chris313AllNight]

So, I have a AX86U running Merlin 388.1 and have recently run into a problem. The wifi on my phone (5 Gig only since I turned off 2.4) has been dropping at random and doesn't reconnect until I go in to wifi settings, choose another SSID, it registers and is fine. Then I switch back to my regular SSID and it registers and acts like nothing happened and it works fine until stops working again,

Question is, is my router radio flaking or is my phone radio dying (Pixel 2 XL got in July of 2019)

 

[Tech Junky]

Phone would be my bet if other wifi devices don't have the issue.

I know on my AP if set my Android streaming box to use SAE vs WPA it will time out and require me to manually connect again but WPA stays connected.

 

[tgl]

I concur with @Tech Junky ... but it might be worth looking into the router's log when this happens, to see if there's any sign of distress beyond the client disconnecting.

 

[bbunge]

It is your setup! Turn the 2.4 GHz back on and use WPA2-PERSONAL. Also use the Dual Band SmartConnect.
Asus factory firmware may help....

 

[Chris313AllNight]

I concur with @Tech Junky ... but it might be worth looking into the router's log when this happens, to see if there's any sign of distress beyond the client disconnecting.

Is there anything I should be looking for specifically in the log? It happened again. Phone dropped off and disconnected. I was testing a Roku box as wireless. That acted a bit slow during this period, but seemingly still worked. Also had an older phone apparently stay connected during this period. I looked in the log and it mentioned more about the Roku losing connection vs the phone that's acting funny

Any insights now?

 

[tgl]

I'm not an expert at reading ASUS logs, but if the router log just shows entries like

wlceventd_proc_event(508): wds2.0.1: Disassoc 7C:10:C9:CB:C1:18, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
eth6: STA 7c:10:c9:cb:c1:18 IEEE 802.11: disassociated

then that's a typical client-initiated disconnection. If it shows a different disconnection reason, or if there are other entries at the same time, that would be worth looking at closer.

 

[Chris313AllNight]

I'm not an expert at reading ASUS logs, but if the router log just shows entries like

wlceventd_proc_event(508): wds2.0.1: Disassoc 7C:10:C9:CB:C1:18, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
eth6: STA 7c:10:c9:cb:c1:18 IEEE 802.11: disassociated

then that's a typical client-initiated disconnection. If it shows a different disconnection reason, or if there are other entries at the same time, that would be worth looking at closer.

Well, this is a section of what I have around when the problem started:

Jan 31 18:44:39 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xeb32 (48/160)
Jan 31 18:46:43 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 84:EA:ED:0E:FC:22, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jan 31 18:46:43 hostapd: eth7: STA 84:ea:ed:0e:fc:22 IEEE 802.11: disassociated
Jan 31 18:46:50 wlceventd: wlceventd_proc_event(505): eth7: Auth 84:EA:ED:0E:FC:22, status: Successful (0)
Jan 31 18:46:50 wlceventd: wlceventd_proc_event(534): eth7: Assoc 84:EA:ED:0E:FC:22, status: Successful (0)
Jan 31 18:46:50 hostapd: eth7: STA 84:ea:ed:0e:fc:22 IEEE 802.11: associated
Jan 31 18:46:50 hostapd: eth7: STA 84:ea:ed:0e:fc:22 RADIUS: starting accounting session 91020D87216EF363
Jan 31 18:46:50 hostapd: eth7: STA 84:ea:ed:0e:fc:22 WPA: pairwise key handshake completed (RSN)
Jan 31 18:46:50 dnsmasq-dhcp[4402]: DHCPREQUEST(br0) 192.168.1.30 84:ea:ed:0e:fc:22
Jan 31 18:46:50 dnsmasq-dhcp[4402]: DHCPACK(br0) 192.168.1.30 84:ea:ed:0e:fc:22 RokuUltra
Jan 31 18:46:50 dnsmasq-dhcp[4402]: DHCPREQUEST(br0) 192.168.1.30 84:ea:ed:0e:fc:22
Jan 31 18:46:50 dnsmasq-dhcp[4402]: DHCPACK(br0) 192.168.1.30 84:ea:ed:0e:fc:22 RokuUltra
Jan 31 18:46:50 dnsmasq-dhcp[4402]: DHCPREQUEST(br0) 192.168.1.30 84:ea:ed:0e:fc:22
Jan 31 18:46:50 dnsmasq-dhcp[4402]: DHCPACK(br0) 192.168.1.30 84:ea:ed:0e:fc:22 RokuUltra
Jan 31 18:46:50 dnsmasq-dhcp[4402]: DHCPREQUEST(br0) 192.168.1.30 84:ea:ed:0e:fc:22
Jan 31 18:46:50 dnsmasq-dhcp[4402]: DHCPACK(br0) 192.168.1.30 84:ea:ed:0e:fc:22 RokuUltra
Jan 31 18:51:08 rc_service: cfg_server 2420:notify_rc restart_wireless
Jan 31 18:51:08 kernel: CFGP2P-ERROR) wl_cfgp2p_find_ndev : p2p inactive
Jan 31 18:51:08 kernel: wfd_unregisterdevice Successfully unregistered ifidx 2 wfd_idx 1
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_add_remove_eventmsg : Get event_msgs error (-19)
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_cfg80211_set_band : seting roam_band failed code=-19
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_cfg80211_stop_ap : Setting band to auto failed
Jan 31 18:51:08 lldpd[2414]: removal request for address of fe80::3e7c:3fff:fe6a:3f5e%27, but no knowledge of it
Jan 31 18:51:08 kernel: br0: port 8(wl1.2) entered disabled state
Jan 31 18:51:08 kernel: device wl1.2 left promiscuous mode
Jan 31 18:51:08 kernel: br0: port 8(wl1.2) entered disabled state
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x2 found! Ignoring event.
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x2 found! Ignoring event.
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x2 found! Ignoring event.
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x2 found! Ignoring event.
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x2 found! Ignoring event.
Jan 31 18:51:08 kernel: CFGP2P-ERROR) wl_cfgp2p_find_ndev : p2p inactive
Jan 31 18:51:08 kernel: wfd_unregisterdevice Successfully unregistered ifidx 1 wfd_idx 1
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_add_remove_eventmsg : Get event_msgs error (-19)
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_cfg80211_set_band : seting roam_band failed code=-19
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_cfg80211_stop_ap : Setting band to auto failed
Jan 31 18:51:08 lldpd[2414]: removal request for address of fe80::3e7c:3fff:fe6a:3f5d%26, but no knowledge of it
Jan 31 18:51:08 kernel: br2: port 1(wl1.1) entered disabled state
Jan 31 18:51:08 kernel: device wl1.1 left promiscuous mode
Jan 31 18:51:08 kernel: br2: port 1(wl1.1) entered disabled state
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x1 found! Ignoring event.
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x1 found! Ignoring event.
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x1 found! Ignoring event.
Jan 31 18:51:08 kernel: CFG80211-ERROR) wl_event_handler : No wdev corresponding to bssidx: 0x1 found! Ignoring event.
Jan 31 18:51:08 lldpd[2414]: removal request for address of fe80::3e7c:3fff:fe6a:3f58%28, but no knowledge of it
Jan 31 18:51:08 kernel: br1: port 1(eth4.501) entered disabled state
Jan 31 18:51:08 kernel: device eth4.501 left promiscuous mode
Jan 31 18:51:08 kernel: br1: port 1(eth4.501) entered disabled state

 

[Chris313AllNight]

Also note that both the phone in question and the Roku box I used for testing are in the same room. You couldn't get better signal unless you were right on top of it. The phone is so close to the router, I could reach out and touch it. It's been that way for years and no issues until now.

 

[tgl]

Hmm ... the "restart_wireless" entry right where the trouble starts at 18:51:08 seems mighty suspicious. On my XT8s, the only entries like that (in the month's worth of logs that I have handy) are from when I was manually fooling with the AP's configuration. I assume you weren't doing any such thing intentionally, but could you have a script or otherwise timed adjustment of the router's config happening in the background?

 

[Chris313AllNight]

Hmm ... the "restart_wireless" entry right where the trouble starts at 18:51:08 seems mighty suspicious. On my XT8s, the only entries like that (in the month's worth of logs that I have handy) are from when I was manually fooling with the AP's configuration. I assume you weren't doing any such thing intentionally, but could you have a script or otherwise timed adjustment of the router's config happening in the background?

I did so some things by hand after this started. (Was messing with the WPA2 settings) So that's probably what you're seeing. I could go back further in the log if you want to see earlier? As far as scripts, if it isn't in the standard Merlin, I don't use scripts.

 

[Tech9]

So, I have a AX86U running Merlin 388.1 and have recently run into a problem.

Read 388.1 release thread. Many AX86U users had Wi-Fi issues with this release. A new test build was posted in Asuswrt with focus on Wi-Fi:

Release - ASUS RT-AX86 Series(RT-AX86U/RT-AX86S) Firmware version 3.0.0.4.388.22068

Regardless of the router IP they should use the URL of: http://www.asusrouter.com

www.snbforums.com

This is perhaps the better strategy - test the base first, then build Asuswrt-Merlin on top. Release 388.1 was built on never released Asuswrt.

 

[Chris313AllNight]

Read 388.1 release thread. Many AX86U users had Wi-Fi issues with this release. A new test build was posted in Asuswrt with focus on Wi-Fi:

Release - ASUS RT-AX86 Series(RT-AX86U/RT-AX86S) Firmware version 3.0.0.4.388.22068

Regardless of the router IP they should use the URL of: http://www.asusrouter.com

www.snbforums.com

This is perhaps the better strategy - test the base first, then build Asuswrt-Merlin on top. Release 388.1 was built on never released Asuswrt.

Thank you, I'll have to give this a try.

 

[Tech9]

I stopped testing 388.1 on AX86U on day one because of Wi-Fi issues. All Asuswrt releases are better, the one 388.1 was based on was skipped and never released as Asuswrt. Current Asuswrt is okay, but has other issues you may or may not see depending on your setup.