GL-AX1800 disconnects some clients from wifi randomly

Hello!

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.

Thank you!

1 Like

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?

Check that the router’s DHCP range is >>60 (e.g., 100), so devices do not run out of IP addresses.

DHCP range is .10 to .254

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.

I am running out of ideas …
For each device in Kasa app, go to Devices Settings → Device Info and check the wifi signal strength.

Last resort … replace those devices :grin: :grin:

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 CanuteTheGreat:

1,Please maintain HT20(802.11b/g/n)and fixed channel configurations. Then exec the following commands and help verify that again:

iwpriv ath1 wapi_rkupkt 10
/etc/init.d/lbd stop

2, If it’s convenient for you, it better have a packet capture with Ominipeek.

Hi. So I did the steps:

iwpriv ath1 wapi_rkupkt 10
/etc/init.d/lbd stop

This seemed to help as we made it 25-26 hours before things disconnected. I will try to get a packet capture tomorrow.

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.

You can test it with 3.209.GL.iNet download center

1 Like