Does effective Simultaneous-Use requires radutmp or database to work OK ?
Hello, In a WPA2 Enterprise wireless environment, I'm trying to control the number of simultaneous connections a user can have. My setup includes Freeradius 3.0.21 from Debian Bullseye's repo. I've seen this Simultaneous-Use setting in documentation. When testing it, I thought I first needed to have radutmp working OK. Unfortunately, my WiFi AP (Unifi AP) do not send NAS-Port AVP in Account-Requests. This seems to prevent radutmp (and checkrad) to work OK. At the same time, I can see meaningful and accurate data in my /var/log/freeradius/racacct directory. So my my question are: 1. When both NAS-IP-Address and NAS-Port are present in Accounting-Requests, is checkrad or radwho using them to send some request to the NAS ? 2. Is radutmp required for Simultaneous-Use enabling ? 3. If radutmp is not required, is an SQL database required for Simultaneous-Use ? Best regards
On 05/04/2022 13:31, Olivier wrote:
In a WPA2 Enterprise wireless environment, I'm trying to control the number of simultaneous connections a user can have. My setup includes Freeradius 3.0.21 from Debian Bullseye's repo.
Rather than answering the question, my advice would be to simply not do that on a wireless network. As a very basic example, wifi devices almost never actually disconnect from the network. They just wander out of range. Which means someone trying to connect to a second AP may not be able to, even if the first device was no longer connected to the first AP, because the original session has not yet timed out. You will cause all sort of problems for your users, and your help desk will hate you with the additional workload. -- Matthew
W dniu 5.04.2022 o 14:45, Matthew Newton pisze:
You will cause all sort of problems for your users, and your help desk will hate you with the additional workload.
Good point. But if you _really_ have to limit this, then please consider periodically closing inactive accounting sessions at least. Back in time this query worked for me: UPDATE radacct SET AcctStopTime=now(), AcctTerminateCause='Stale Record' WHERE AcctStopTime is NULL and (TIMEDIFF( now(),acctstarttime)) > TIME('24:00:00') -- Marek Zarychta
Le mar. 5 avr. 2022 à 14:51, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> a écrit :
W dniu 5.04.2022 o 14:45, Matthew Newton pisze:
You will cause all sort of problems for your users, and your help desk will hate you with the additional workload.
Good point. But if you _really_ have to limit this, then please consider periodically closing inactive accounting sessions at least. Back in time this query worked for me:
UPDATE radacct SET AcctStopTime=now(), AcctTerminateCause='Stale Record' WHERE AcctStopTime is NULL and (TIMEDIFF( now(),acctstarttime)) > TIME('24:00:00')
@Matthew, @Marek: Reading your messages again, I'm realizing having an accurate picture of connected and disconnected devices will be a long and tough road, in wireless world. I'm looking for a way to prevent some users to resell WiFi access to each other but probably not at the cost of severly degrading user experience or flooding help desk. My questions remain but maybe I should look for delayed analysis of past records rather than a system relying on live ones. Thank you very much for your inputs.
On 05/04/2022 14:19, Olivier wrote:
I'm looking for a way to prevent some users to resell WiFi access to each other but probably not at the cost of severly degrading user experience or flooding help desk.
My questions remain but maybe I should look for delayed analysis of past records rather than a system relying on live ones.
Yes, I would do this. Analyse the logs, pick off the accounts with a lot of devices connected, investigate. -- Matthew
Le mar. 5 avr. 2022 à 14:45, Matthew Newton <mcn@freeradius.org> a écrit :
On 05/04/2022 13:31, Olivier wrote:
In a WPA2 Enterprise wireless environment, I'm trying to control the number of simultaneous connections a user can have. My setup includes Freeradius 3.0.21 from Debian Bullseye's repo.
Rather than answering the question, my advice would be to simply not do that on a wireless network.
As a very basic example, wifi devices almost never actually disconnect from the network. They just wander out of range. Which means someone trying to connect to a second AP may not be able to, even if the first device was no longer connected to the first AP, because the original session has not yet timed out.
Yes, of course. How are these session timeouts defined ?
You will cause all sort of problems for your users, and your help desk will hate you with the additional workload.
-- Matthew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Marek Zarychta -
Matthew Newton -
Olivier