@stephenw10
I believe I can finally put this project in perspective for all of us.
The reconciliation of the 32 bit unsigned int overflow so that pfSense knows the actual value of max-octets-total in freeRadius will enable you to track a "single session" against the correct pfSense-Max-Total-Octets in pfSense/Captive Portal. From that perspective this is a valid improvement.
The above achievement is flawed in that total traffic in pfSense/Captive Portal is only maintained for the active session or duration of pfSense powered up state. This means it tracks the traffic data on a single user session between session start and either logout or in this case a traffic quota based on a valid freeRadius supplied pfSense-Max-Total-Octets. A reboot or power loss will result in the pfSense Captive Portal session surviving if "Preserve connected users across reboot" is checked, i.e. True, but the traffic quota cumulated to date in pfSense will be lost on a reboot or power loss and restart from 0. This means pfSense is not capable of tracking a single user session against the freeRAdius max-octets-user value because the traffic to date value is not persistent. But... it is persistent to the nearest accounting interval on freeRadius because it uses a physical storage on a hard drive file, which survives both a login/out session, and reboot, be it deliberate or power related. freeRadius typically autosums all open user sessions to the main used-octets-user file on a restart. pfSense Captive Portal will force the creation of new used-octets-user-uniqueID files on freeRadius after the restart at the appropriate interim accounting interval.
If the captive portal is set to "Multiple" under Concurrent user logins, there will be multiple active sessions for the same user account under pfSense. Each separate session is checking that session's traffic against the pfSense-Max-Total-Octets value so it will not logout either user until that individual user reaches the pfSense-Max-Total-Octets value which is not the intent at freeRadius. On the freeRadius side, it will cumulate all users together into used-octets-user based either on stop/start or if set to interim, based on the interim interval value set on freeRadius, it will create a used-octets-user-uniqueID value for each user which are only summed to the main used-octets-user file when each individual user logs out. Although this is by design on the freeRadius side, it could be considered a bug because a logout will not be initiated by freeRadius until the used-octets-user exceeds the max-octets-user setting. Thus, neither pfSense, nor freeRadius will log all users out unless something intervenes and forces summation of all the used-octets-user-uniqueID files into the used-octets-user file that freeRadius uses to determine if the quota was breached.
Yes, this now accurate pfSense-Max-Total-Octets value tracked against a single session user for an uninterrupted session will force a captive portal traffic quota related logout, which in turn will force freeRadius to sum all the uniqueID files into the main used-octets-user file but it will not do so in captive portal: "multiple" Concurrent logins mode as it is tracking each individual user against pfSense-Max-Total-Octets instead of summing all the authenticated users on that user account together first. Thus "multiple" is not supported.
freeRadius has all it needs to do both multi users per account and session interruption tracking if pfSense was to force the summation of the uniqueID files into the used-octets-user file on a regular basis. This is why stop/start freeRadius solves this problem and works perfectly. Unfortunately that solution is not elegant and has serious scaling issues.
As we already have a working solution in stop/start all we need to do to get interim to use freeRadius to accurately invoke pfSense-Max-Total-Octets is to regularly fire one stop/start accounting packet session. I suggest when you select interim, you add a gui option to set a "cumulate every ??? seconds" option and point out it should be at least as large as the freeRadius interim setting (default 600 seconds). Once this is done, pfSense Captive portal in cooperation with freeRadius through the interim accounting period set on freeRadius will enforce the pfSense-Max-Total-Octets in all scenarios.
As I said in the outset, the correct determination of the pfSense-Max-Total-Octets is irrelevant other than if the above is implemented, it will fix the failure of either freeRadius or pfSense to accurately track pfSense-Max-Total-Octets when interim sessions are still active within this "powered session".
in the above scenario. reauthenticate every minute does not appear to have purpose other than to force freeRadius to check max-octets-user against used-octets-user once a minute. As it does NOT force the cumulation of the multiple used-octets-user-uniqueID files into the used-octets-user file, it is not a tool to address the multiple user under interim setting issue. If it did, it would also be a solution to the tracking of multiuser traffic.
The above assumptions have been lab confirmed on 23.01RC 08 Feb 06:00 version, in both single and multiuser mode.
See #13843 & #13418 for historical information
