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

"Rainer Sinsch" <(E-Mail Removed)> hath wroth:

>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.

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

>Now if I turn off the client (abruptly, no dissassociation involved), how
>can the AP find out that the client is not connected anymore?

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.

>Will it be
>connected forever,

No.

>will there be some kind of timeout (on the base that the
>client does not send any packets anymore),

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.

>or is there some kind of
>"is-alive frame" outgoing from the AP involved?

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.

>What does the 802.11 standard say about this?

It's 2AM and I'm not going to risk my sanity by reading the docs at
this hour. RTFM thyself:
<http://standards.ieee.org/getieee802/>
You'll need to read at least:
802.11-1999
802.11b-1999
802.11b-1999 Corrections 2001
802.11g-2003

>Thanks in advance

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

So, what are you trying to accomplish?

>Rainer

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

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.

>>will there be some kind of timeout (on the base that the
>>client does not send any packets anymore),
>
> Yes. However, there are actually several timeouts. Since the access
> point controls the connection, it's usually the access point that
> initiates a disconnect.

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.

>>or is there some kind of
>>"is-alive frame" outgoing from the AP involved?
>
> 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.

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?

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

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

/rainer

"Rainer Sinsch" <(E-Mail Removed)> hath wroth:

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

Yep. Answers without context tend to be overly general.

>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.

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:
<http://amltd.com/pdf/commandlink_userguide.pdf>
See page 34 some details on how their timeouts work. It might give
you a clue on how it *SHOULD* work.
<http://amltd.com/m7100.asp>
It does barcode. (Sorry, no experience with the product).

>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.

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?

>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.

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).

>The scanners I played with took about
>Another thing is that both
>our RF-environemnt and logs gets filled up with senseless reauthentication
>packages.

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.

Questions:
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?

>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.

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.

>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).

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 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.

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.

>>>will there be some kind of timeout (on the base that the
>>>client does not send any packets anymore),
>>
>> Yes. However, there are actually several timeouts. Since the access
>> point controls the connection, it's usually the access point that
>> initiates a disconnect.
>
>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.

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?

>>>or is there some kind of
>>>"is-alive frame" outgoing from the AP involved?
>>
>> 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.
>
>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?

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....
--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann <(E-Mail Removed)> hath wroth:

>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.

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 7.3.1.7 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) */

Translation:
- 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.
http://madwifi.org/changeset/450
http://madwifi.org/browser/cvs-impor...node.h?rev=450
The tweaking never ends...

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Rainer,

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

Regards,

Aaron

---


~ 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.
~
~ >>will there be some kind of timeout (on the base that the
~ >>client does not send any packets anymore),
~ >
~ > Yes. However, there are actually several timeouts. Since the access
~ > point controls the connection, it's usually the access point that
~ > initiates a disconnect.
~
~ 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.
~
~ >>or is there some kind of
~ >>"is-alive frame" outgoing from the AP involved?
~ >
~ > 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.
~
~ 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?
~
~ > You might change your mind about thanking me after you read the IEEE
~ > docs.
~
~ Yeah, they read dryly, but I will have a look at them anyway.
~
~ /rainer
~