Weird behaviour of sqlcounter / dailycounter

[Martin Edge]

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 at lists.freeradius.org> On Behalf Of Robert Senger
Sent: Wednesday, May 31, 2023 3:44 PM
To: FreeRadius users mailing list <freeradius-users at 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 at 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