Why do client devices in the client list of a router or AP randomly go in and out, even though they aren't disconnecting?

Lord Evermore

Ars Scholae Palatinae
1,490
Subscriptor++
Often when I'm trying to troubleshoot or monitor a network issue, I notice that Wi-Fi clients in the connected client list of a router or AP will drop, then reappear. Sometimes even wired devices disappear and reappear but it's less often. It's either immediate, a few seconds, or even minutes before they show up again. Sometimes a client doesn't show up for quite a long time. During this time, the device doesn't actually lose connectivity, and can be running a download with no problems. If for some reason it was disassociating and reassociating, I'd expect it to reappear very quickly (within whatever refresh time the code of the page allows) otherwise the device's download would suffer. Sometimes manually disconnecting and reconnecting will restore it. And of course the wired devices are not losing connectivity.

I've just set up my Asus router in AP-only mode to use instead of my cable gateway. I saw that sort of thing on both devices, though. Even though I was actively connected from my phone to the Asus, it wasn't showing the device at all until I disconnected and reconnected, and then it popped up instantly. But if I went to the System Log and checked the wireless log (which is really just a static status output, not a log), the phone was there the whole time. Two other devices are also listed in the log, but they aren't appearing in the client list at all either. They actually all disappeared when I manually changed the channels used for both bands, but they are all connected, just not showing as clients. And even though my phone showed up after reconnecting, a couple of minutes later it disappeared again, then showed up again a few minutes later. At the same time, even all the wired devices that are seen through the connection to the cable gateway disappeared, but NOT the gateway itself, then they showed up again.

Is this just flaky code on particular devices? I've seen this behavior on many devices, but it's usually just APs that I was monitoring. But that includes both standalone APs, APs managed by a local software or hardware controller, and those managed by a cloud controller. Is the client list the result of active scanning and for some reason it sometimes doesn't get results, so client devices are removed from the list?
 

Paladin

Ars Legatus Legionis
32,552
Subscriptor
You'd have to ask the people that wrote the router software how they qualify whether to list the client device. It may be as simple as it having a short timeout period for that list and if the device doesn't talk specifically to the router, it drops it from the list. Basically you have to know how they define 'connected'. Wifi Association state? ARP entry? Recently seen traffic? Active TCP session? NAT table entry? MAC table entry? Every router or AP may have different qualifications and each have different value for people looking for different information.
 

tiredoldtech

Smack-Fu Master, in training
84
Subscriptor++
Fully agree as @Paladin stated. More so, it may be down to 'polling' intervals. I've seen even professional/enterprise devices do such a thing. The disappear/reappear just happens to do with timing of when the units are polled on the network and response vs showing in that exact display report. A printed/saved file report may not show it dropping as it never actually did, but the 'polled' display will show devices missing as they just didn't happen to respond inside the specific polling response time. Some network devices only respond every so often- whereas a 'poll' may be looking for a response sooner than later.

I used to most definitely experience this with old Buffalo WHR-HP-G54 units that a hotel put up as AP's that we had to support years ago (worked for a contract consulting firm/MSP at the time). The difference was, even with custom firmware- when units dropped from the Buffalo units, it sometimes took the better part of a day to come back on the display list, making it a pain for device management (block listing, etc) as they were managed from that screen of what they could see.
 

Xelas

Ars Praefectus
5,444
Subscriptor++
I have not seen that kind of behavior with good Wi-Fi systems (Aruba, Cisco, Meraki, or even Unifi). Unify has (had?) weirdness in that clients would show up as wired instead of wireless, be shown connected to the wrong AP, etc, but they would show up somewhere.
I think those Buffalo APs were re-branded OpenMesh units, IIRC. OpenMesh was a bit iffy and laggy because their cloud infrastruture was very minimalistic and the devices only ping back to the cloud on a very infrequent basis. I have not worked with them since they've been acquired by Datto.
Consumer-grade crap? You can expect anything. I've seen "routers" fail to show all of their DHCP leases, too, or even fail to load their internal pages at all because BusyBox crashed or ran out of RAM.
 

Xelas

Ars Praefectus
5,444
Subscriptor++
I saw it on UniFi APs in my last job, both when using a local software controller and a cloud controller.
Unifi doesn't have a cloud controller. They have "cloudkeys", which are just an onsite controllers that are poorly named. In fact, their security is so appallingly poor* that you really need to use dedicated cloudkey for every LAN anyway, which does not scale well when trying to manage many sites. When you allow cloud access, all you really do is get remote access into that cloudkey from the internet.
Unifi has had innumerable bugs and execrable (pretty much non existent) firmware testing, so I'm not surprised that they may had had this wifi client listing issue come up with some firmware releases.

* The "inform" handshaking protocol uses the same identical MD5 hash (the MD5 hash of the string "ubnt") to encrypt all device "inform" traffic. When a device is (re)adopted (like after a firmware update) the inform traffic is used to exchange encryption keys between the device and the controller, but since this MD5 hash is an open secret, it is trivial to sniff the inform traffic, gain access to the encryption keys, and thus gain access to all traffic to/from the remote devices.
 
  • Wow
Reactions: continuum

Lord Evermore

Ars Scholae Palatinae
1,490
Subscriptor++
Unifi doesn't have a cloud controller. They have "cloudkeys", which are just an onsite controllers that are poorly named. In fact, their security is so appallingly poor* that you really need to use dedicated cloudkey for every LAN anyway, which does not scale well when trying to manage many sites. When you allow cloud access, all you really do is get remote access into that cloudkey from the internet.
Unifi has had innumerable bugs and execrable (pretty much non existent) firmware testing, so I'm not surprised that they may had had this wifi client listing issue come up with some firmware releases.

* The "inform" handshaking protocol uses the same identical MD5 hash (the MD5 hash of the string "ubnt") to encrypt all device "inform" traffic. When a device is (re)adopted (like after a firmware update) the inform traffic is used to exchange encryption keys between the device and the controller, but since this MD5 hash is an open secret, it is trivial to sniff the inform traffic, gain access to the encryption keys, and thus gain access to all traffic to/from the remote devices.
Well consider my entire argument invalidated, I guess. :rolleyes: