Forum

Hello,

I have a question.

How is an AP recognize that a client is no more connected, if the client don't send a deauth by itself (for exampel suddenly power off the client). Is there a timeout mechanism within 802.11 standard?

I know about backoff and retransmission timers for frames, if it is not Acked by Client, but I can not remember that there is a timeout or something like that, that cause the AP to stop sending traffic to the disconnected client.

It would be nice, if you can jog my memory ;)

Thank you.

Different manufacturers have different policies - often based on a maximum client capacity parameter.   At some point, this can be part of the AP manufacturers "secret sauce".

The operation I most often see occurs when a client just stops responding (hangs), and the AP drops the client from its active list after a few minutes.

A WLAN admin in a big shop could give you a better answer for the specific AP hardware they use.

I base my response on what I know of the Cisco Unified solution, since it's not regulated by any formal standard as far as I know. What I mean by that is if a client simply leaves the BSS without sending a disassociate-message (which is in the standard but not required to be sent) then the AP has no means of knowing it is no longer connected.

Cisco uses a default time-out of 5 minutes. If after 5 minutes a client still didn't send any frame then the entry is removed from the database (in the controller in the case of a unified solution). You can send a disconnect-message from the controller to the AP which will 'kill' the client immediately and thus remove it from the database. Works like a charm, but it's a manually invoked disconnect. 

Again, a client isn't required to send a disassociate-frame, which would clear the database-entry in the AP/controller so the AP needs to use some sort of timer (like the 5 minutes) to make sure the client isn't just sleeping or just out of reach for a few seconds.

Arjan

Hi Arjan,

Quick question: The "client association time-out timer" of 5 minutes in the Cisco controller (or Cisco AP) is it configurable

in your system? (in the GUI or in the CLI). I am searching for that option (High Density Moving Clients, like stations/trains

type of environments providing public traffic. Every 1-2 minutes there is a train arriving at the station with 1000+ Wi-Fi clients

and people go in/out, so we need fast time-out timers, 5 minutes is too long).

Your question as far as I know it is not defined in the IEEE 802.11-2012 / 802.11-2016 standard (but if someone on this forum knows

let us know the exact IEEE 802.11 standard clause describing it).

A method I can think off is that the AP detects the "Probe Requests" (either directed or null-requests) for roaming purposes

and to keep the list of active APs in the clients memory, but the AP also sees these Probe Req. and determine if the client is 

still active.  (another method I can think off, if a more advanced AP has a 2nd radio in promiscuous/monitor mode, like a 

sensor radio, then a vendor possibly can use that feature to see if the client is still active transmitting to its own AP or a 

neighbouring AP as long it is in the sensors' reach to hear these transmissions between the client and the other AP).

Other items can be related to roaming (which is defined in the IEEE standard, see also CWSP-205 for more details)

If the client leaves the "ESS" (Extended Service Set), thus 2 or more APs with the same SSID  (either standalone AP 

or controller based APs or cooperative control based APs). And the environment is either a mobility environment (seamless

roaming) or a portability environment (connection breaks, but the client does the full frame connection setup sequence to the

new AP). 

It depends on the roaming solution you use:

* std 802.11  (slow) roaming  (and frame exchanges over the Distribution System  (the backbone ethernet at L2)

* Roaming with pre-authentication enabled (in client's supplicant and on the AP)

* Roaming with PMK-Caching enabled  (in client's supplicant and on the AP)

* Roaming with OKC  (proprietary)

* Single Channel Architecture (SCA) roaming (like vendors as Fortinet/Meru, Allied Telesys, Extricom, etc.)

* IEEE 802.11r  (Fast Secure Roaming / Fast BSS Transistion)  either over-the-air  or over-the-ds  (distribution system)

* IEEE 802.11p  (WAVE - Wireless Access in Vehicular Environments).  I do not have experience with this one and not

  sure if it has been implemented or used  (if anyone knows let me know)

* IEEE 802.11s  (Mesh) I have seen this one implemented for roaming purposes in Vehicular environments and requires

very fast hand-over times   (think about Construction sites  or  self-driving trucks in mining environments).

Hope this helps.

Ronald   CWNE #108

Hi Ronald,

The Cisco timeout of 300 sec. is the default. This is the user-idle-timeout and can be/is coupled to an amount of data a user has sent within a specified period (the mentioned 5 minutes when left default). Honestly, I haven't played with that timer but this is what is does.

Now, normally you won't be specifying an amount of data, but since it is part of the configuration I guess I need to mention it to be complete in my answer :-)
There's a CLI-command and a GUI-config, so which ever suits you best. You can set the client timeout within the range of 15 - 100.000 sec. or 0 to disable it. It's done on a per-WLAN basis, so luckily not a global setting.

CLI: config wlan usertimeout <sec> <wlan-id>
GUI: Navigate to 'WLANs'  --> WLANid you want to edit --> Advanced tab --> 'Client user idle timeout (15 - 100000)' en enable it (+ edit the required #seconds)

Hope this helps. If you want, I can give it a try in my lab if time permits.

Arjan

Today we discussed this in class as well. One of the students is managing a large network and he mentioned he is using this feature

on the Cisco infrastructure, but there is another issue when clients go idle (like phones to save on their battery life) and the applications

are not running on the device itself (e.g. when all the applications are closes) it gives issues to stay connected to the infrastructure

(I do not have the details or protocol captures), but the student mentioned they advice to leave the applications running (as these

apps still send regularly data over the network and keeps the connectivity). Probably more people "tweeted" about this on twitter,

I remember that Ben Miller ("Ben Sniff Wi-Fi") has a post about iphone: 

http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html

Agreed, but back to the original question and your question Ronald: An AP simply has no idea if a client is still really connected or pulled an Elvis on you (i.e. has left the building).

Your question regarding shortening the detection-time for railway-stations and such would be feasible using the user-idle-timeout.

Have a great training!

Arjan

I'd never searched through the  802.11-2012 spec. for "timeout" before.    After going through about half of it (whew), I gave up after not finding anything that looked relevant.     There are hundreds of entries that match this simple search.

Naturally, almost every operation has some kind of timeout or other.

The only thing I learned is that 802.1x has its own timeout variables.

Sorry I couldn't be of more help.

Hello everybody,

thanks for all the responses and interesting information and implementations.

Backgound of my question was, that I saw different behavior auf two APs (called AP1 and AP2) by handling the following scenario.

3 clients getting a UDP video multicast stream (which is send as multicast to unicast conversion via wifi to each client), which they requested via IGMP.

Then one of the clients is powered off. So, there is no mechanism on higher layer that recognize it is missing (like tcp got) and also apparently, no implementation of the standard that recognize a missing station.

AP1 is still sending the video stream to the missing client, also without any response from it. But this, in turn, occurs to picture fragments and stopping of the video by the other two clients, until AP1 has stopped to send it to the missing client (I think the standard IGMP timeout encroaches here after ~60seconds). I think sending the stream to the missing station farther, cause some burst and jitter for the overall video stream, which cause the video fragments?!

AP2 stops sending the videostream to the missing station after ~10s. I don't know by which implementation, maybe after some missing Ack/Blk Ack from the station?! But this is short enought, that the other clients can run the video without big influences in the video stream.

Globeron,

Ben Miller's post on iPhone behavior was really eye opening !

For several years now, people have been promoting setting DTIM parms to 1 to improve performance.   Yes, they usually said it might hurt battery life, but never anything bad about performance. 

Apple has always had a different drummer.