pfSense

I can confirm that start/stop freeRadius does handle data quota tracking for a freeRadius User. I tested 2 simultaneous connections to one user account and that too tracked data usage reasonably accurately.

Previously start/stop in this 23.01 Dev release (Dec 30th) was disconnecting the user pre-maturely for Over Quota. The issue now is that the 2 simultaneous user connections above hit the quota and carried right on without the Captive Portal logging a Quota limit reached disconnect. It is not clear if this is by design but turning on Reauthenticate every minute should correct this (I will confirm). The problem with the Reauthenticate every minute option is that it fills up the System Log with authentication messages. On a moderately loaded system (50-100 freeRadius authenticated users) I found in 22.05 that those log entries could no longer keep up and in fact the reauthenticate occurred more like 10-20 minutes apart. It would be helpful if the frequency of Reauthenticate every minute included the ability to set the number of minutes and to enable/disable the System Log entries each time it does. I am looking to turn off the log and Reauthenticate every 30 minutes for example.

Can you enable quota checking in start/stop as that would simplify the implementation? The reference is compare the used-octets-user total to the max-octets-user total in freeRadius, both I believe are in the accounting packet sent back to pfSense from freeRadius.

You'll have the same observed behavior as 'reauthenticate every minute', since accounting start/stop is done at minute intervals.

Scratch that, I misunderstood what you were saying. I'll have to look at the code some more. I would expect the minute interval pruning task would be able to log the user off as you did. There may be an additional bug here.

I think I understand the disconnect here - Start/Stop requires resetting the rule counters in the firewall, and only the radius server knows the cumulative usage from the user, and as you've identified the captive portal code is not checking the response attributes after sending an accounting stop. As a result, we are currently reliant on an auth request to tell us to log the user off. Interim updates, however, do not reset the counters and the captive portal pruning task can see directly that the user's rule counters have exceeded the limit configured for the RADIUS user and determine without reauth that the quota is exceeded.

The accounting response is not required to contain any attributes, but I'd consider this a bug if the input and output octets attributes might exist in the response and we don't check it. I'll create a new issue to track it, and if you're satisfied that start/stop accounting is now accurate we can close this one.

I can verify at this time that freeradius as configured by the pfsense package does not include any attributes in the accounting response.

Yes, but I did not check Interim updates for logout on Quota yet. I doubt that will work because captive portal does not know the starting count in used-octets-user unless freeRadius puts it into the accounting packet for captive portal to add into its cumlulative usage info so you will be hitting the quota based on all the logged in users if it does not add in used-octets-user, the exact opposite problem from what we had before.

Either way, Reauthenticate every minute does the login check and correctly logs out the user based on the start/stop data in used-octets-user. This is because unlike interim, it does not create separate unique used-octets-user-"mac" files (unique ID per mac) that remain unsummed to used-octets-user until the user actually logs out. This is particularly important for simultaneous logins per single user in freeRadius.

The argument I can give that captive portal gets the used-octets-user and max-octets-user counters in the accounting packets should be contained in the code for Reauthenticate every minute because it correctly handles them and logs out all users when used-octets-user exceeds max-octets-user. I can even modify used-octets-user on the fly and have captive portal disconnect correctly (if and only if Reauthenticate every minute is selected).

Thanks for the quick work on this, major step forward!

It sounds like you have fixed the primary problem, a way to track Data usage by simultaneous users logged into one freeRadius user account and disconnect them when the sum of their usage exceeds the quota set in freeRadius. The tracking is done by start/stop freeRadius and the logout is done by the Reauthenticate every minute option.

The reauthenticate every minute option does not scale well. I was getting sporadic log entries with 50-100 users in perhaps 25 user accounts on a 20 minute basis rather than the 62 second basis it does on a lightly loaded pfSense. the Sys Log just can't handle the quantity of log entries as it does 2 lines for every authenticated user and has to log them out individually when the main freeRadius User account exceeds Quota. For example, the Reauthenticate finds one user over quota and logs them out, 20 minutes later, based on the sys log entry, it finds another one and logs them out, even though they were on the same user account. With 22.05 all that quit working altogether with the loss of Data tracking. 22.01 still had these scaling issues.

Thus, we can work with this but Captive Portal control of Reauthenticate timing and getting rid of the load on Sys Log by turning off logging would be welcome improvements.

Subject to the above, you have corrected the original issue with start/stop.

Dale Harron wrote in #note-7:

Yes, but I did not check Interim updates for logout on Quota yet. I doubt that will work because captive portal does not know the starting count in used-octets-user unless freeRadius puts it into the accounting packet for captive portal to add into its cumlulative usage info so you will be hitting the quota based on all the logged in users if it does not add in used-octets-user, the exact opposite problem from what we had before.

This should not be the case. Every authenticated user has their own counter rules in the firewall tracking the in/out bytes for that session. When the prune task is run and interim accounting updates are selected, the counters for a user are summed to a used bytes count and in addition to being sent to the accounting server they are compared to the pfSense-Max-Used-Octets value recorded for the user on authenticating. If the used data exceeds this quota, the user is logged out of the captive portal and their usage must then be reset on the accounting server in order to authenticate again.

Interim accounting updates differ from start/stop accounting in that there is only one accounting start/stop session and the interim updates include the current running tally for the accounting session, not a delta. As a result, the rule counters do not need to be cleared at each update and maintain a session total. This will likely not be feasible for large quotas, however, as we'll be hitting MAXINT on octet counts as I identified in #13823, and octet counts meeting or exceeding 4096MB before a user is logged out will overflow. This is a limitation of RADIUS itself as integer accounting attributes in the protocol are 4 bytes wide. See https://freeradius.org/rfc/rfc2866.html#Acct-Output-Octets for example.