GL-AX1800 disconnects some clients from wifi randomly

GL.iNet Routers Technical Support
#1

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
#2

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.

#3

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.

#4

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.

#5

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.

#6

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!

#7

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?

#8

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

#9

DHCP range is .10 to .254

#10

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.

#11

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:

#12

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.

#13

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)

#15

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.

#16

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.

#17

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.

#18

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

1 Like