Identify: short 802.1X EAP-PEAP sessions with Acct-Terminate-Cause = 105

[gherbiet]

Hello community,

I have set up an EAP-PEAP 802.1X SSID in bridge at EWC topology on a cluster of C5210 running 09.21.16.0013 (as we need to support a couple of 3600 series APs). I have seen a couple of changes in 9.21.17.0006 related to RADIUS but I don't think it is related to the problem I am facing.

The RADIUS authentication is performed by a FreeRADIUS server (version 2.2.5, installed from packages on a Debian "Jessie" 8.8).

I have noticed that a lot of users are experiencing very short sessions (in the order of 0 to a few seconds) that terminate with an Accounting-Stop message with the Acct-Terminate-Cause attribute set to "105". When the end-devices have stored the network credentials then authentication reoccurs. However, when this is not the case they are just disconnected from the network and do not reconnect.

On the controller side, the relevant options are:

In "VNS" / "Global" / "Authentication" / "RADIUS Servers" / "RADIUS Settings" (click on the RADIUS Alias in the Servers table:
- Interim Accounting Interval: 5 (minutes)
- Send Interim Accounting Records for: Fast Failover Events: checked

On the same page, on the "Advanced" window, "RADIUS Accounting" is checked as well.

Finally under "VNS" / "WLAN Services" / "" / "Auth & Acct", in the "Radius TLVs" (that shall spell "RADIUS TLVs" btw), all VSAs are checked, "Replace Called Station ID with Zone name in RADIUS Requests" is unchecked.

On the RADIUS server side, the relevant attributes associated to users that face this issue are as follows:
- Idle-Timeout := 600

I use the same RADIUS server with Wi-Fi network from other vendors and I did not face this issue.

Do you have an idea of what might cause the controller to prematurely stop the RADIUS session, especially with this this Acct-Terminate-Cause value (that is not documented in RFC 2866) ?

[Umut_Aydin]

Hi Guillaume-Jean,

this happens CHANGED_WLAN_SERVICE if the user need or should change his SSID/TOPOLOYG(VLAN) after succesfully authentication.
Since he stuck in the old SSID IP world the client doesn't renew his IP.
Therefore if you wanted change the WLAN ( to other SSID ) then you need lower the DHCP lease time so that the Client ask faster for his new IP .

This point provides improvements.

1.Change unauthenticated behavior to "Discard Unauthenticated Traffic" in the non-auth policy.
2.Super low lease timer in the start off topology.
3.Under the MAC Authorization Config, checking the option "RADIUS Accounting begins after MAC-based authorization completes".

Regards

Umut

[gherbiet]

Hello Umut, Thanks for your quick reply. I suppose the source code abstract is from the EWC software. Are other non-standard Acct-Terminate-Cause values available somewhere (as this can be useful for any further troubleshooting). Can you also clarify when this CHANGED_WLAN_SERVICE condition is raised? Is this when the user changes IP address? The VNS associated with the SSID where the problem arises uses the same role for Non-Authenticated and Authenticated users. In the logs and the RADIUS accounting, I see that for the short sessions may have or not have a valid associated IP address (some have 0.0.0.0 or an IP in the link-local range). The network where the SSID is deployed is known to have a slow DHCP server (IP address attribution can take several seconds). For the IP range associated to the SSID, lease has been set to a long value (1 week) as this is supposed to help troubleshooting. Would the option "Defer sending the accounting start request until the client's IP address is known." in the "VNS" / "Global" / "Authentication" / "Advanced" section help? If not, I will make a request for the DHCP lease to be reduces (then is a value of a few hours suitable?). Regards,

[Umut_Aydin]

Hi,

the meaning of this should be

Acct-Terminate-Cause attribute set to "105".

--> #define CHANGED_WLAN_SERVICE 105

Look if the user get IP in the new SSID?

Decrease the leased time on DHCP Server?


Regards
Umut