radius attributes supported on WLC 2504

[Alexander Proskurnin]

Hi all!

I can't find any info about which AAA attributes are supported by WLC2504 (ver 8.3.102.0). Especially I'm interested in AVP Idle-Timeout. It seems like it's not supported but I search for a proof of it.

Thanks in advance.

[Haydn Andrews]

Are you talking about idle timeout which is configured on the WLC > Controller User Idle Timeout (seconds), if so this is a global configuration that can not be controlled via AAA override for a individual user.

If your talking about:

Session timeout look at AVP Session-Timeout

[Arne Bier]

Hi @Haydn Andrews 

How come idle-timeout cannot be set on a per user basis?  Does the WLC just ignore the AVP?

I have not had much joy with idle-timeout on WLC in general - perhaps my testing was skew, but I didn't see the session terminate when I had hit the threshold (min/max traffic).  Have you had any luck with it?

[Haydn Andrews]

Hi @Arne Bier 

Is there an AVP called usertimeout?

Just saw that this is configurable per WLAN:

https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_0100110.html

[Arne Bier]

The IETF attribute is called idle-timeout

https://tools.ietf.org/html/rfc2865#section-5.28

I am pretty sure that the WLC supports this - and when you check the client session details then it should have been overridden with the value sent in the Access-Accept.

[Alexander Proskurnin]

Here the output from WLC. And it correctly recognizes AVPs:

*radiusTransportThread: Mar 27 15:09:02.272: Packet contains 2 AVPs:

*radiusTransportThread: Mar 27 15:09:02.272: AVP[01] Idle-Timeout.............................0x3b9aca14 (1000000020) (4 bytes)

*radiusTransportThread: Mar 27 15:09:02.272: AVP[02] Session-Timeout..........................0x3b9aca14 (1000000020) (4 bytes)

but the only option it overrides is sessionTimeout:

*apfReceiveTask: Mar 27 15:09:02.273: 1c:cd:e5:3b:0c:c8 Override values for station 1c:cd:e5:3b:0c:c8
source: 2, valid bits: 0x100
qosLevel: -1, dscp: 0xffffffff, dot1pTag: 0xffffffff, sessionTimeout: 1000000020

WLC still uses global idleTimeout 300 seconds.

[Haydn Andrews]

What code version are you running on WLC?
Is this command available from WLC CLI

config wlan usertimeout timeout-in-seconds wlan-id

[Alexander Proskurnin]

Hi, Haydn!

ver 8.3.102.0

This command is available, but I need to override it by AVP from radius.

(Cisco Controller) >config wlan usertimeout ?
<seconds> Client Idle timeout(in seconds) on this WLAN. Range 0,15-100000 secs. 0 to disable

[Haydn Andrews]

The way the doco is written it is a per WLAN setting. I know older versions it was a per wlc setting.

Interested to know the use case of why u need it different on a per user/user group.
https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_0100110.html

This is an enhancement to the present implementation of the user idle timeout feature, which is applicable to all WLAN profiles on the controller. With this enhancement, you can configure a user idle timeout for an individual WLAN profile. This user idle timeout is applicable to all the clients that belong to this WLAN profile

Feom that my understanding is it would not be able to be changed via AAA override

[Alexander Proskurnin]

>>> Interested to know the use case of why u need it different on a per user/user group.

I use open network with captive portal and wanted to use Radius to make client idle timeout infinite, so once identified on the portal clients will forever be authorized.

Something like sleeping client feature but it's also configured on the WLC per WLAN and can be maximum of 30 days.

[Scott Fella]

For portal pages, sleeping client needs to be used. Idle timer is not used for that and is limited on length. It’s different if you use ISE or another 3rd party portal, where they can cache the device for longer or for specific timeframe. 

[Alexander Proskurnin]

We don't know what can be done with ISE 'cause we don't have it :) but our 3rd party portal do cache users for configurable time but this is not enough. Here is what's happening:

1. new user connect to open wifi network

2. user completes identification on the portal and by redirect to 1.1.1.1/login.html gets authorized on the network

3. after some network activity user disconnects

4. now he may come next day or in a month and connect to wifi network

5. when this happens controller does not have state for this client and forward request to portal just to press "go to internet" button, so by default without some additional user actions in the browser there will be no internet access.

It seems like I need to rethink about access to wifi network, because all those questions/problems comes from the willing to make one network for both guests and employees.

[Scott Fella]

What you need to use is sleeping client which can go up to 39 days I believe. You leave idle timer alone at 300 and do whatever you want for session timer.  This only works if the wlc is hosting the portal page, but if you have a 3rd party tool that is doing the portal page, it might not work. 

[Scott Fella]

There really is no reason to touch the idle timeout. Keep in mind that the idle timeout has to be lower than the session timeout. The idle timeout works if the device goes to sleep and doesn’t respond to the AP stating it’s still there. Testing idle timeout, basically walk out of range from the wireless coverage area. Session timeout is a hard timer as long as the idle timeout doesn’t expire. These days, I typically don’t even have the session timer enabled and idle timer at default.

I’m curious on what you are trying to achieve and wondering if that would cause instability for user experience.