Weird behaviour of sqlcounter / dailycounter

[Robert Senger]

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