@Hank21 Hi, I think I made some progress late lasy night, but to answer each of your questions.
For 2.4 and 5G, how about you just make one SSID each?
I tested a lot and it certainly seems to be this particular SSID, as other don't seem to kick clients at all. It's just that most clients in my home use this SSID on 2.4GHz.
I use both, but this one is dedicated for IoT devices and some other things.
Does this problem occur lately?
It has not occured in my memory, I recently reverted to using this EAP245v1 as the primary AP, wheras before it was part of an Omada cluster using the same SSIDs and authentication.
By what means is it powered? The original power adapter—do you use it? Kindly check that there is sufficient power available.
Using the official power adaptor supplied with the AP, no problems I could see with the adaptor. It's not getting hot either or anything strange.
Additionally, the unit is on a APC unit, and the power is measured as abundant and stable.
Change the Ethernet wires that were used to connect it to the internet is another choice you have.
I did change out the ethernet cables, and used a different port on the switch, one of the first things I did. Issue persisted.
Additionally, consider adjusting certain wireless configurations to enhance the network performance as there could be channel issues causing the clients to disconnect.
I haven't set a static channel but I have done a lot of other config variations, in small changes to test if there is something meaningful.
Now I will talk about my findings as of late last night/this morning's testing.
I think I found something interesting, and I have successfully replicated it multiple times to confirm.
So, as I indicated before, I reduced the SSIDs down to 2x 2.4GHz SSID configurations, and I commenced with modifying the troublesome one "WuTangLAN" to see if I can find something interesting.
To summarise, I noticed through testing that by using Security Mode WPA-PSK (WEP is not considered, and WPA-Enterprise is too much trouble for this particular) is mandatory for all this testing. Now, the Version and Encryption is where things get interesting.
Setting Version to WPA-PSK works fine, and I know many IoT devices will struggle with WPA2-PSK, so it's WPA-PSK for 2.4GHz. It is what it is.
Setting Encryption to TKIP is where this seems to exibit the same behaviour, the clients connect, and after some time the AP kicks everyone from the SSID (Other SSIDs keep clients), now unfortunately TKIP is probably the widest supported but I don't like to use it, still it's an option as of now.
Setting Encryption to AES, however, has proven more stable, and does not seem to be kicking clients YET. It's been up for a few hours without kicking anyone, but I suspect not all clients are connected so some are missing (Which I will need to investigate which are having issues, if any). The devices I don't see in particular without diving deeper are a few kWh meters that are very recent from 2022 and should be fine, but I need to investigate further. It may just be that they are in an error state from being fed up being kicked and need to be cycled of forced, remains to be seen.
I think that the Version/Encryption "Auto" setting uses TKIP more often, but I cannot see anywhere to prove this exactly, apart from the resulting number of clients seems lower than expected. In my opinion, MAYBE one of the clients is doing something unexpected and the AP kicks EVERYONE from the entire SSID and refuses any more connections? Seems like weird behaviour. The resource usage is low, CPU is consistently 8-13%, the memory is always around 49-51%, doesn't seem to be under strain for 30-35 mostly low traffic clients.
This definitely seems like a software bug to me.
I'm not sure if time would be put into investigating this, and I doubt they would do that for such an old model anyway.
For the record, I added back both the 5GHz SSIDs.
All 5GHz SSIDs are left Security Mode WPA-PSK, Version "Auto", Encryption "Auto".
The 5GHz SSIDs do not seems to exibit any issues kicking clients, from the beginning of all of this.
This is the current situation since this morning:
This is the configuration that doesn't work, clients get kicked:
This also doesn't work, same behaviour as before clients get kicked:
This seems to work (for now) but I think not all clients are conencting: