802.11 - When does a client assoc end?

Johannes Luther · ‎11-06-2009

Hi board,

I have a tiny understanding problem regarding client-associations in 802.11.

If a client associates to an AP, the AP adds the client to it's association table. How does the standalone AP or the WLAN controller determine the IP-address of the client? The WLC or AP need this AP for local ARP-responding (it's even mandatory for a WLC solution, because ARP packets never travels over the air!!).

Does the WLC gain the clients IP by sniffing traffic or with the local-DHCP relay (or both?!).

An autonomous AP isn't a DHCP-relay - how does an IOS AP learn the IP address of an associated client?

Ok - this was the first part of my question. Now for something different

As soon as the client is associated, it's in the association table of the WLC or IOS-AP. So far so good.

Now, if the radio interface of the client is shut down (no disassoc-frame), my understanding is, that an idle-timer decreases and when it's zero, the client is removed from the list - right?

What's about "silent" client - like a linux host? This thingy is not brabbling like a Windows PC. How does this type of client stay associated? I couldn't find anything in the IEEE 802.11 standard.

So - has the client to send keep-alive packets? I guess so! There's nothing like a probing of the AP.

Hope you can help and thanks in advance!

dennischolmes · ‎11-06-2009

DHCP relay by proxy. It uses the address of the virtualinterface to request a dhcp address for the client then relays that address back. The client will remain associated until the AP reboots or the client sends a disassociation packet by the standard. Most APs and the controllers from Cisco have an idle user timeout setting that disassociates the client from the AP.

Johannes Luther · ‎11-06-2009

Thank you for your reply. So you're stating, that the WLC learns the IP address of the client by proxing DHCP requests. What's about wireless client with static IP's? Are you sure the WLC doesn't learn the clients IP by checking the IP header?

Because of the idle-timer.

At an IOS AP the default timeout is 60 seconds, and modifiable with "dot11 activity-timeout"

At a WLC, I'm not quite sure - there is a "wlan"-timeout (config wlan timeout)

and a "usertimeout" (config network usertimeout)

wlan-timeout:

To change the timeout of wireless LAN clients, use the config wlan timeout command.

"user-timeout:

To change the timeout for idle client sessions, use the config network usertimeout command. Use this command to set the idle client session duration on the Cisco Wireless LAN controller.

This is copied and pasted from the Command-Lookup Tool. So I'm totally confused now :-) What setting does what?

Could it be, that one is a global setting (usertimeout) and may be overrided with the wlan-timeout?

The documentation is a little bit poor here - at least I couldn't find anything.

dennischolmes · ‎11-06-2009

idle user states if a client goes idle and no traffic is observed by the controller then the session is ended at the dtermined time. 5 minutes by default. WLAN timeout states the time a client session is allowed to exist from the WLAN data base entry perspective. The WLAN would then force the client to reauthenticate to insure security.WLAN is more client based wher user idle is user role based.

Johannes Luther · ‎11-06-2009

Yeah - right, I remember.

The wlan timeout is a non-refreshable timer. When it's down, the client needs to perform a 802.1x reauth.

For pre-shared keys, the PTK has to be re-derived by doing the 4-way handshake again.

Do you have any clue about the other topics I wrote? Like how does the IOS-AP and the WLC learn the clients IP