Weird behaviour of sqlcounter / dailycounter
Martin Edge
medge at neverathome.net
Wed May 31 05:55:29 UTC 2023
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
More information about the Freeradius-Users
mailing list