Weird behaviour of sqlcounter / dailycounter

[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.