Hey Robert, Is that not saying that there is no 'Session-Timeout' attribute in the reply in this circumstance? Do you see the attribute set within the reply packet from the auth request? "(342) ERROR: Failed retrieving values required to evaluate condition" Perhaps you need to check the attribute is present within the check condition first? Thanks Martin. -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+medge=neverathome.net@lists.freeradius.org> On Behalf Of Robert Senger Sent: Wednesday, May 31, 2023 3:44 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Weird behaviour of sqlcounter / dailycounter Hi Alan, thank you! I did not set a time resolution of one second, this is done by the sqlcounter module with it's default settings. I was looking for a configuration option like "Min-Session-Timeout" or something like that, but there is none.
post-auth { if (&reply:Session-Timeout < 30) { reject } ... }
This looks good, just tried that (in the sites-available/default file), but won't work: (342) post-auth { (342) if (&reply:Session-Timeout < 30) { (342) ERROR: Failed retrieving values required to evaluate condition ? :) Robert Am Dienstag, dem 30.05.2023 um 22:52 -0400 schrieb Alan DeKok:
On May 30, 2023, at 8:37 PM, Robert Senger <robert.senger@lists.microscopium.de> wrote:
The situation is that the station trying to connect is allowed a Max- Daily-Session of 300 seconds. The counter is at 299, so sqlcounter correctly sets Session-Timeout = 1, and the station is allowed access for one second remaining...
That is very much not going to work. Most NASes will not deal well with Session-Timeouts that small.
It's more common to set Session-Timeout to larger values, like 5 minutes.
However, this connection is terminated immediately by the Wifi AP (running hostapd 2.due to Session-Timeout = 1.
i.e. the *used* session time is zero. So the server never gets an accounting packet with Acct-Session-Time = 1, and the counter is never changed.
So the next time the user tries to log in, he will get Session- Timeout = 1 again.
The counter never gets increased, the station retries and is allowed access, and every 5 seconds or so this repeats and repeats and repeats... The logs get flooded and there's useless load on the AP and freeradius. The station (Linux machine with NetworkManager) stopped trying to connect after half an hour or so...
So... don't set Session-Timeout = 1?
This isn't really a FreeRADIUS issue. The RADIUS protocol can only handle times based on seconds. Sub-second resolution isn't supported.
This behaviour is reproduceable. Every time the station's Max- Daily- Session value is reached and it get's kicked off by the AP, it get's into this loop. The number of retries until the station finally is giving up is significantly higher if more than one AP with the same SSID is reachable (>30 minutes). This behaviour also occurs if the "counter" module is used rather than the "sqlcounter" module.
Freeradius version is 3.0.21, hostapd version is 2.10-8.
Did I configure something wrong, or what happens here? Thank you for help!
The solution is a post-processing state, say in the "post-auth" section:
post-auth { if (&reply:Session-Timeout < 30) { reject } ... }
i.e. "if they have less than 30 seconds of time remaining, just reject them".
There is no good way to allow sub-second session timeouts, or sub- second Acct-Session-Time. The RADIUS protocol doesn't support that.
So you're left with a time resolution of one second. And even then, the RADIUS client is likely to not deal well with very small values in Session-Timeout.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -- Robert Senger - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html