authenticating and de-authenticating so many times
Not your router specific but the quoted behaviour you’re observing is something I’ve been seeing with my IoT devices, specifically Shelly’s.
There’s quite a few things going on in parallel it seems and some of it is down to IoT devices themselves and some to how Asus decides which device goes where.
I note you’re using Main plus AP nodes, which means unlike AiMesh, your guest or IoT (GNP) networks set up in GNP are not propagated to the nodes. So I’m assuming your 2.4Ghz network is set up for IoT device, if you’ve split them,
IoT Devices Deciding
So in relation to the IoT Devices, some have poor FW (if they’re sophisticated enough to have any) and most have weak Wi-Fi. In my Shelly’s i could (and needed to) tighten the RSSI at which each determined (by itself) to roam to a node, so that that connection was strongest and they stayed there, no Auth deauth.
Once tightened enough it did this properly but what I and some others see often is that
1. When the routers boot up (certainly in AiMesh mode) the IoTs join the main first as it seems to wake first, as long as that ‘just’ satisfies the RSSI criteria, or
2,.They join the Router with the strongest TX signal, more on that below, which cannot be adjusted per Node in AiMesh, but IIRC can be in AP mode, so you may have an option there to tweak TX balance.
Unsophisticated IoTs will probably just join to the strongest router signal, or have at best a preset RSSI at which they roam.
My observations here was that if the RSSI was too loose, but close to what they might roam at, they attached themselves to one node, ran off to a better one, came back, constantly connecting and disconnecting like some duck being fed bread by several different people, then fell off completely.
Router Side
On the router side you have Roaming Assist (RA) which most folks will rightly IMO tell you to disable for 2,4Ghz (IoT) devices as they are generally fixed in place.
Most folks will say set Static IPs on rage devices if you can; i do this as well as DHCP assignments on the router. If you cannot do the former, the latter helps if nothing else, than identification. It may help initial attachment, but I cannot vouch for that.
Most folks will say use WPA2 for IoT devices as especially older or poorly implemented ones struggle with WPA2/WPA3 mixed or above.
Similarly, as you have done,most recommend 2.4GHz channels 1, 6 or 11 (1 is slightly further from microwave frequency I believe, but crowded) and 20MHz, not 20/40. I personally left mine at 20/40 as I still want older IOS devices to connect at reasonable speed or to reach further away devices that drop off 5Ghz onto 2.4, at a decent speed. My Chromecast is a case in point.
There’s a few wireless professional settings some swear by (or at, if it’s not going well) like disabling Beam forming or TX Burst etc etc, but I started out and tried to stay as close to stock settings as possible amd these didn’t help in my case.
Then you have Smart Connect whose job it is, if you have a combined 2.4 and 5GHz SSID, to trigger/steer devices to the 2.4Ghz or 5Ghz network based on signal strength. A combined SSID is probably rare for those with IoT devices and using APs as the advice is always to separate them, but with AIMesh I left it combined as I can make them join a 2.4Ghz SSID in GNP using an IoT network. Still, if you do have APs it’s a potential issue as SC also comes into play, trying to steer (if strong) a 2.4GHz IoT device to a 5GHz band, which it will never connect to. The best parallel I can think of is trying to mate the two sides of Velcro strips, only the grippy side facing each other mate, no other option exists.
I have (separate thread) run scripts on each node to see what the device sees as RSSI at the node and what RSSI the Router sees at the router, which is interesting. They can be quite different and have helped me at least understand why a particular device is still in a node at a weak RSSI and hasn’t moved to and stayed on a better one.
The above are all settings in the GUI, I’ve played around with some things under the hood like when to flush ARP (essentially a record of connected / previously connected devices) cache as the timing of it forgetting these may have coincided with when my devices were trying to reconnect. IMO if you have to resort to this sort of tuning something’s gone wrong.
Sorry for the long winded post, hopefully it gives you if nothing else, some food for thought ND you get yours sorted out, but there’s a lot of things at play and I think it’s incredibly difficult without the granularity of eg power adjustments per node or per SSID even, to get all devices working as one might expect.
