wireless controler issue

[Albert Paul Raj Vathamanickam]

Cisco 5508

Once a guest connects to wireless lan, they are displayed a "disclaimer" and then the session should run for 3 hours without seeing the disclaimer.

If the session disconnects before 3 hours and re connects, they are presented with the dicslaimer again , and they shouldnt be.

Would you be able to confirm if my understanding is correct?

Please advise.

Thanks.

Albert

[Amjad Abdullah]

Hi Albert,

Actually when clients connect (with disclaimer) and disconnect again they still can re-connect without seeing the disclaimer within a specific period of time.

This specific period of time duirng which the disconnected clients can connect without disclaimer is called: user-idle timeout.

The default value of this timeout is 300 seconds ( 5 minutes ). So if you have WLC with default config the users can disconnect and if they try to connect again within 5 minutes they will connect without seeing the disclaimer page.
This valud is configurable under WLC GUI -> Controller -> General.

It is a global value that will affect all your SSIDs and not only one WLAN.

HTH

Amjad

[Albert Paul Raj Vathamanickam]

Hi Amjad,

Thanks for your reply.

The disclaimer is set under Security, Web Auth Web login page.

Under WLans, select the SSID you want to apply the rule to and the advanced tab. We have changed the setting to 10800 or the equivalent of 3 hours, which worked initially but it doesn't work now.

If a user connects and agrees to the disclaimer, disconnects and reconnects inside the 3 hour window, they are being presented with the disclaimer. They should not be.

Would you be able to point me in the correct direction?

Thanks.

[Amjad Abdullah]

Albert:

Feom advanced settings you can configure session timeout that is related to layer 2 and timer for it resets with every new association for the client.

User idle timeout however does not reset until the timer expires (even if the client get disconnected on layer 2 level) so if the client disconnects and connects again before expiration its info is still known for the wlc as running client.

Try increasing idle timeout and let me know if it works.

Amjad

[David Santos]

Just for info:

A. The ARP Timeout is used to delete ARP entries on the WLC for the devices learned from the network.

The User Idle Timeout: When a user is idle without any  communication with the LAP for the amount of time set as User Idle  Timeout, the client is deauthenticated by the WLC. The client has to  reauthenticate and reassociate to the WLC. It is used in situations  where a client can drop out from its associated LAP without notifying  the LAP. This can occur if the battery goes dead on the client or the  client associates move away.

Note: In order to access ARP and User Idle Timeout on the WLC GUI , go to the Controller menu. Choose General from the left-hand side to find the ARP and User Idle Timeout fields.

The Session Timeout is the maximum time for a client session  with the WLC. After this time, WLC de-authenticates the client, and the  client goes through the whole authentication (re-authentication) process  again. This is a part of a security precaution to rotate the encryption  keys. If you use an Extensible Authentication Protocol (EAP) method  with key management, the rekeying occurs at every regular interval in  order to derive a new encryption key. Without key management, this  timeout value is the time that wireless clients need to do a full  reauthentication. The session timeout is specific to the WLAN. This  parameter can be accessed from the WLANs > Edit menu.

@ http://www.cisco.com/en/US/products/ps6366/products_qanda_item09186a00808b4c61.shtml

[Scott Fella]

There has been a lot of discussion regarding this.  The one way to make sure they don't get the disclaimer is to increase the ARP timeout to 10800 (3 hours).  iOS devices seem to be the devices that users complain about having to log back on when the device turns off/sleeps.  Increasing the ARP timers does also increase the CPU so you need to monitor that.  Session timeouts should also be increased, which you have already done.