anastrophe
Occasional Visitor
I have a 'Ting' electrical system monitor - amazing device - reported loose neutral on mains, PG&E checked even though they didn't believe it could diagnose it - neutral into mains apparently had never had its retaining screw tightened since house built in 1987! - But I digress.
A few weeks after updating my RT-AX3000 to 3004.388.5 (just a correlation), my Ting device (which can only do 802.11n) reported it couldn't connect to wifi. It had been connected - less than ten feet away (100% signal) - to the 802.11n network on the Asus router for a couple of years. But after a few hours, it reconnected on its own without issue.
Then yesterday, the Ting device disconnected again and I could not get it to reconnect after resetting it. The logs on the Asus - which provides DHCP across my network including three TP-Link extenders (Two RE505X v1.0 and an RE450 for guest net) - showed that DHCP discovered the device, offered an IP, got an ACK from the Ting, but then would disassociate and after repeated tries by the Ting device it would fail - "reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0". Rebooted router, same. Had not made any changes to the router config since the firmware update. Contacted Ting, since it appeared that the device could be corrupted or failing in some other way. This morning I got a reply asking me to go through the standard scripted list of steps again, unplug router, etc etc, even though I'd provided them with a section of the logs showing how it was failing. I was writing a lengthy peeved response (coffee not onboard yet), 'I know what I'm doing, decades as sysadmin, LAN/WAN engineer', etc etc....But I figured I should do due diligence and try through a different wi-fi device just for shirtes and giggles - one of the RE505X extenders.
It immediately connected and is happily connected to the RE505X - with the same IP address as the Asus would delegate when it failed on its own wifi. What. The. Heck!!
I updated to 3004.388.6 and tried again on the main router, same failure - again, just a weak correlation, I don't think it's Merlin but can't say for sure. I can connect a freshly powered-up cellphone to the Asus router's 802.11n just fine. I'm at a loss as to what the failure mode here is.
Relevant Asus settings are
802.11n "N only"
WiFi Agile Multiband "Disable"
Target Wake Time "Disable"
Channel bandwidth "20/40 MHz"
Control Channel "Auto Current Control Channel: 10"
Extension Channel "Auto"
Authentication Method "WPA2-Personal"
WPA Encryption "AES"
WPA Pre-Shared Key (lol nope)
Protected Management Frames "Capable"
Group Key Rotation Interval "0"
I believe all the other associated tab values are at defaults, I don't believe I've mucked with the "Professional" tab settings (is there an easy way to snarf configs such as these in text format?)
Attached is full log since reboot on 3004.388.6 (just to be thorough), ends at the failed DHCP session
And here's just the end of the log after reconnecting device through RE505X, completely uneventful:
Jan 20 14:15:34 dnsmasq-dhcp[2039]: DHCPDISCOVER(br0) c4:7f:51:a6:89:8b
Jan 20 14:15:34 dnsmasq-dhcp[2039]: DHCPOFFER(br0) 192.168.1.190 c4:7f:51:a6:89:8b
Jan 20 14:15:34 dnsmasq-dhcp[2039]: DHCPREQUEST(br0) 192.168.1.190 c4:7f:51:a6:89:8b
Jan 20 14:15:34 dnsmasq-dhcp[2039]: DHCPACK(br0) 192.168.1.190 c4:7f:51:a6:89:8b Ting-8B-89
Thoughts??
A few weeks after updating my RT-AX3000 to 3004.388.5 (just a correlation), my Ting device (which can only do 802.11n) reported it couldn't connect to wifi. It had been connected - less than ten feet away (100% signal) - to the 802.11n network on the Asus router for a couple of years. But after a few hours, it reconnected on its own without issue.
Then yesterday, the Ting device disconnected again and I could not get it to reconnect after resetting it. The logs on the Asus - which provides DHCP across my network including three TP-Link extenders (Two RE505X v1.0 and an RE450 for guest net) - showed that DHCP discovered the device, offered an IP, got an ACK from the Ting, but then would disassociate and after repeated tries by the Ting device it would fail - "reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0". Rebooted router, same. Had not made any changes to the router config since the firmware update. Contacted Ting, since it appeared that the device could be corrupted or failing in some other way. This morning I got a reply asking me to go through the standard scripted list of steps again, unplug router, etc etc, even though I'd provided them with a section of the logs showing how it was failing. I was writing a lengthy peeved response (coffee not onboard yet), 'I know what I'm doing, decades as sysadmin, LAN/WAN engineer', etc etc....But I figured I should do due diligence and try through a different wi-fi device just for shirtes and giggles - one of the RE505X extenders.
It immediately connected and is happily connected to the RE505X - with the same IP address as the Asus would delegate when it failed on its own wifi. What. The. Heck!!
I updated to 3004.388.6 and tried again on the main router, same failure - again, just a weak correlation, I don't think it's Merlin but can't say for sure. I can connect a freshly powered-up cellphone to the Asus router's 802.11n just fine. I'm at a loss as to what the failure mode here is.
Relevant Asus settings are
802.11n "N only"
WiFi Agile Multiband "Disable"
Target Wake Time "Disable"
Channel bandwidth "20/40 MHz"
Control Channel "Auto Current Control Channel: 10"
Extension Channel "Auto"
Authentication Method "WPA2-Personal"
WPA Encryption "AES"
WPA Pre-Shared Key (lol nope)
Protected Management Frames "Capable"
Group Key Rotation Interval "0"
I believe all the other associated tab values are at defaults, I don't believe I've mucked with the "Professional" tab settings (is there an easy way to snarf configs such as these in text format?)
Attached is full log since reboot on 3004.388.6 (just to be thorough), ends at the failed DHCP session
And here's just the end of the log after reconnecting device through RE505X, completely uneventful:
Jan 20 14:15:34 dnsmasq-dhcp[2039]: DHCPDISCOVER(br0) c4:7f:51:a6:89:8b
Jan 20 14:15:34 dnsmasq-dhcp[2039]: DHCPOFFER(br0) 192.168.1.190 c4:7f:51:a6:89:8b
Jan 20 14:15:34 dnsmasq-dhcp[2039]: DHCPREQUEST(br0) 192.168.1.190 c4:7f:51:a6:89:8b
Jan 20 14:15:34 dnsmasq-dhcp[2039]: DHCPACK(br0) 192.168.1.190 c4:7f:51:a6:89:8b Ting-8B-89
Thoughts??