My finance and I have an GL-AX1800 that has been working great (we love it, we also have a GL-AR750S for travel) for all client devices except 6 of them. The ones in question randomly get disconnected and do not attempt to reconnect. This happens between 1 and 10 times per day. These devices work fine with our 3 other, older APs (the latest one is being replacing with the GL-AX1800, the rest of disconnected/in storage except for testing) and only exhibit the disconnect with the GL-AX1800. All other client devices work perfectly. When the issue happens, whatever it it, all 6 devices get disconnected within seconds of each other.
So we have 3 wired client devices, ~50 2.4 GHz client devices, and ~10 5 GHz client devices. Out of those only 6 of the 2.4 GHz are having any issues. From that 50 2.4 GHz group we have 21 of them that are TP-Link Kasa smart devices (plugs, strips, lights, outlets, and cameras) and the 6 misbehaving devices are among them (4 outlets, 1 power strip, 1 light). However, the remaining 15 devices do not have any issues including some brand new devices and some much older ones. The firmware on all of the Kasa devices are up-to-date.
Again, when connected to any one of our older APs they work fine (tested for 3 weeks, 2 weeks, and 4 days with all of them.) Does anyone have a suggestion on how to resolve this as whatever the problem is seems to only exist with these 6 devices and the GL-AX1800.
I have 4 Kasa smartplugs that run on schedules and find that the same 1 or 2 may sometimes be disconnected when I open the Kasa app. The schedules still run and they eventually do reconnect. They are not connected to a GL.iNet router.
You can try changing the channel on the 2.4 GHz band. Maybe the old routers were on different channels.
Try latest Firmware. Try a different channel. Change the bandwidth to 20 Mhz. When I had the 2.4G set to 40Mhz and 20/40Mhz older devices had issues with disconnects.
These 6 devices never reconnect. Tried leaving them sit for 48 hours with no reconnection. Powercycling each one individually is the only way to get them to reconnect.
We have tried 4 different channels including trying the optimize option to find a channel. no change in behavior.
Firmware is 3.208 no newer firmware is found from the “UPGRADE” menu. Channel for 2.4 is on 20/40. I will change it to 20 immediately and report back tomorrow.
It has been 14 hours and so far no disconnects. Normally I would have had 1 or 2 by now. I will give it the rest of the day, but hopefully setting the channel width to 20 did the trick!
Okay so the problem still exists, but it definitely took longer before it triggered this time (19 hours). I will keep the 2.4 GHz at 20 MHz. Any other suggestions or thoughts?
Perhaps change the Lease time to a shorter interval or 0 so that the lease never expires. Create static leases for these IOT. It seems that some devices are going into a hibernate mode turning off the WIFI radio. Look at the system logs in LuCi they might tell you something.
The questionable devices (and some others) have static DHCP assignments. The signal strength is not the issue (3 of them are in the same room!) I will look closer at the logs.
So looking through the system log in luci, I have a lot of entries like the below one. A lot as in once per minute! Some of the entries are from the misbehaving devices, but not all of them.
Fri Jan 21 14:47:46 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e IEEE 802.11: disassociated
Fri Jan 21 14:47:50 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e IEEE 802.11: authenticated
Fri Jan 21 14:47:50 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e IEEE 802.11: associated (aid 5)
Fri Jan 21 14:47:50 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e WPA: sending 1/4 msg of 4-Way Handshake
Fri Jan 21 14:47:50 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e WPA: received EAPOL-Key frame (2/4 Pairwise)
Fri Jan 21 14:47:50 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e WPA: sending 3/4 msg of 4-Way Handshake
Fri Jan 21 14:47:50 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e WPA: received EAPOL-Key frame (4/4 Pairwise)
Fri Jan 21 14:47:50 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e RADIUS: starting accounting session 48299A00F20E8C07
Fri Jan 21 14:47:50 2022 daemon.info hostapd: ath1: STA d8:07:b6:7e:e3:9e WPA: pairwise key handshake completed (RSN)
Fri Jan 21 14:48:11 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 IEEE 802.11: disassociated
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 IEEE 802.11: authenticated
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 IEEE 802.11: associated (aid 1)
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 WPA: sending 1/4 msg of 4-Way Handshake
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 WPA: sending 1/4 msg of 4-Way Handshake
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 WPA: received EAPOL-Key frame (2/4 Pairwise)
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 WPA: sending 3/4 msg of 4-Way Handshake
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 WPA: received EAPOL-Key frame (4/4 Pairwise)
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 RADIUS: starting accounting session 9710DB30EDB6908F
Fri Jan 21 14:48:15 2022 daemon.info hostapd: ath1: STA d8:0d:17:e7:da:d4 WPA: pairwise key handshake completed (RSN)
Hi. So we are still fighting with this issue. Some updates: We recently moved and are still seeing the same behavior so I think they rules out something environmental/interference. I have not had good luck getting a capture since the issue only happens about one per day now. The best I can do is a ~64mb capture from Wireshark for one day.
Update date in case anyone else runs into a similar situation: It has been a long time coming, but I think I finally found the problem. I could never find any issues in wireshark. Recently I set up remote logging on both of the Slate AX1800s to a Linux machine that has rsyslog configured to receive and noticed that a particular mac was attempting to connect almost every second (with the occasional pause that would last for a few minutes or so). Googling the mac showed it was manufactured by Tuya Smart Inc. After a lot of testing (basically unplugging every smart device in the house for a few minutes, turning breakers off in the electrical box, etc.) we eventually narrowed things down to one room. Once we began looking at what was plugged in, we discovered it is a “smart” thermometer. Sure enough, this thing has wifi, and was not connecting correctly. After removing the power (ac and batteries) the constant connection attempts stopped. At that point we did a factory reset on the “smart” thermometer and it has been behaving since (about 2 months now).
