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.