How does an AP know if a client is still connected?

Hello everyone,

I have a theoretical question about wireless networks in general. Let's assume the following scenario:

A client connects to a wireless access point. It therefore authenticates and associates and as a result has full access to the network. Internally the AP has registered the client.

Now if I turn off the client (abruptly, no dissassociation involved), how can the AP find out that the client is not connected anymore? Will it be connected forever, will there be some kind of timeout (on the base that the client does not send any packets anymore), or is there some kind of "is-alive frame" outgoing from the AP involved?

What does the 802.11 standard say about this?

Thanks in advance Rainer

Reply to
Rainer Sinsch
Loading thread data ...

"Rainer Sinsch" hath wroth:

Ok, the client now has an IP address assigned by the access point.

Easy. Just ping the clients IP address. If the client doesn't respond to ping, use a MAC based ping such as ARP PING.

There will also be status information on the connected clients signal strength and SNR. If your unspecified model access point supports SNMP, this is directly accessible. Otherwise, you may need to scribble a script to scrape the access point status page for the required numbers.


Yes. However, there are actually several timeouts. Since the access point controls the connection, it's usually the access point that initiates a disconnect. However, the client can also issue a disconnect request. This really gets messy when the client is setup to do roaming between multiple access points. The connect and disconnect timing and sequence is usually highly creative for roaming.

There is a keep alive coming from the client. The idea is to keep the connection alive even if there is no data traffic. However, even with no data traffic (i.e. no payload), there is plenty of management traffic between the client and access point. Strictly speaking, the keep alive is not needed or could be considered optional.

It's 2AM and I'm not going to risk my sanity by reading the docs at this hour. RTFM thyself:

You'll need to read at least: 802.11-1999 802.11b-1999 802.11b-1999 Corrections 2001 802.11g-2003

You might change your mind about thanking me after you read the IEEE docs.

So, what are you trying to accomplish?

Reply to
Jeff Liebermann

Hi Jeff,

thank you very much for your detailed answer. Perhaps I should have written why I'm asking this question:

We are using wireless barcode scanners that only send TCP/IP traffic when doing a barcode-scan. Now if there is no scanning done (and no TCP/IP traffic is sent) the scanners get disconnected from our APs after 180 seconds. After that, the clients directly reconnect again. We can see this clearly in our logs and we have been told by the AP manufacturer that the

180 seconds timeout is hardcoded into the firmware and can not be changed.

The problem with this behaviour is that the reconnection process takes some time (802.1x authentication + dhcp request) and during this timeframe the scanner hangs and cannot be used for scanning. Another thing is that both our RF-environemnt and logs gets filled up with senseless reauthentication packages.

Personally I don't want to believe that a hardcoded automatic disconnection after 180 seconds idle time is part of the 802.11 standard so I'm looking for some documents that describe this behaviour. Also I'd like to know if this is the case for all 802.11 APs or just the case for our manufacturer (I don't want to paste the name here, but it's an industrial AP and not a low-budget one from BestBuy). I can also imagine that this is a problem from a bad 802.11 implementation on our barcode-scanners. I just want to clarify the problem and have a look at possible solutions.

That is true. In our case it is 180 seconds. We have sniffed the wireless traffic and can clearly see the deauthentication frame outgoing from the AP.

Now this sounds interesting. Could you elaborate on this? What kind of management traffic is this? If this is the case then our barcode-scanners shouldn't be disconnected, should they?

Yeah, they read dryly, but I will have a look at them anyway.


Reply to
Rainer Sinsch

"Rainer Sinsch" hath wroth:

Yep. Answers without context tend to be overly general.

Are the scanners going into some kind of power save mode? That's typical of the scanners I'm familiar (ancient Intermec and Symbol). If you're not sure, run the timeout test by yanking the battery from the scanner before it has a chance to initiate a disconnect. It's possible that the scanner issues a disconnect, deauth, or disassociate packet before going into power save.

I did some googling and blundered across this document. It's a Linux based handheld terminal:

See page 34 some details on how their timeouts work. It might give you a clue on how it *SHOULD* work.

It does barcode. (Sorry, no experience with the product).

See what clearly? Is the access point really initiating the disconnect? Or is it just responding to a disconnect request from the scanner just before it goes into power save?

Yep. However, I think you might be trying to "solve" this problem in a rather backwards manner. The scanners I played with only used WEP so reconnects were considerably faster. It was about equal to the time it took for the mirror to spin up and/or the CPU to restart. The users would just push the trigger at the floor, wait a few seconds, and then it was ready. My guess(tm) is about 5 seconds maximum.

How long does yours take? (Hint: No numbers, no indication of progress and no comparisons).

That sounds more like an interference, collision, or signal strength problem. The re-auths are not senseless. They're an indication of loss of connection, lost packets, excessive retransmissions, or sufficient interference that the AP gives up and wants to start over. It also might be trying to roam/switch between access points.


  1. More than one access point? How many?
  2. All the same SSID?
  3. All the same RF channel? Auto channel selection? I'm trying to get a feel for what's causing the log to fill with what I'm guessing are attempts to find a better connection.

Have you tried testing this under ideal conditions?

I'll look in the IEEE docs. It's in there, somewhere. Reading the IEEE docs tends to turn by brain to mush, so please ignore any future incoherent babbling.

Bad idea. If some manufactory screwed up on anything other than a security issue, I believe it should be plastered all over usenet and the web until it's fixed. I've found that this is often the only way to get their attention. In trade, you are responsible for posting the inevitable outcome of your investigation which includes that the product might have some problems.

I've seen considerable creativity in following the 802.11 specifications. Disconnect behavior is intimately entangled with roaming ability and seems to be a target for tinkering. However, it's usually the client that requires the tinkering to fix roaming. As far as I know, the access point timing is usually fairly close to whatever is recommended in IEEE 802.11-1999.

Ok, so it's the AP that's initiating the disconnect, not the client. Presumeably, it's because of the timeout, not because of interference or packet loss, etc. Duz the log file give a reason for the disconnect or an "initiated by...." tag?

If the managment traffic, which sends signal strength, SNR, and other goodies back and forth all the time ever stops, I guess the 3 minute timer starts. That can only happen if the bar code scanner goes into power save mode and shuts up completely.

Digging in the specs....

Reply to
Jeff Liebermann

Jeff Liebermann hath wroth:

I couldn't find anything in IEEE-80211-1999 specifying a disconnect timeout of 180 seconds. However, I may have missed it.

However, the following might be of interest:

802.11-1999 Reason Code field. This should explain WHY it disconnected, deauthenticated, or disassociated. You're assuming it's due to an access point timeout, but I'm not so sure.

Ah, foundit. Source is all over the web. Search google for "IEEE80211_INACT_RUN" It's originally from the BSD and GNU sources as: $NetBSD: ieee80211_node.h,v 1.7 2003/10/29 21:50:57 dyoung Exp $ #define IEEE80211_INACT_WAIT 15 /* inactivity interval (secs) */ #define IEEE80211_INACT_INIT (30/IEEE80211_INACT_WAIT) /* initial */ #define IEEE80211_INACT_ASSOC (180/IEEE80211_INACT_WAIT) /* associated but not authorized */ #define IEEE80211_INACT_RUN (300/IEEE80211_INACT_WAIT) /* authorized */ #define IEEE80211_INACT_PROBE (30/IEEE80211_INACT_WAIT) /* probe */ #define IEEE80211_INACT_SCAN (300/IEEE80211_INACT_WAIT) /* scanned */ #define IEEE80211_TRANS_WAIT 5 /* mgt frame tx timer (secs) */


- Inactivity timeout doing nothing = 30 seconds

- Inactivity timeout after association, but not authorized as in encryption key not exchanged successfully = 180 seconds

- Inactivity after key exchange = 300 seconds

- Timeout waiting for answer to probe request = 30 seconds

- Timeout for probe scan of available access points = 300 seconds

- Timeout waiting for a management frame = 5 seconds

It appears that if you have an existing connection, then the timeout should be 300 seconds, not 180 seconds. However, that assumes that the AP initiated the disconnect due to a simple timeout, not a series of lost packets, lousy signal, or interference. Check the reason code in the log file.

Here's an example of MadWiFi screwing around with the timing by lowering the IEEE80211_INACT_ASSOC from 180 seconds to 120 seconds.

formatting link
tweaking never ends...

Reply to
Jeff Liebermann


There is certainly nothing in 802.11 that mandates that the AP disconnect a client after 180 (or any other number of) seconds of idleness. If your APs cannot be reconfigured to avoid behaving like this, then I would recommend upgrading to a different manufacturer's APs - unicast me and I'd be glad to offer an impartial recommendation ;)



Reply to
Aaron Leonard Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.