Bug #2710
closed
Captive Portal radius accounting negative session time
0%
Description
I use captive portal with a separate freeradius server with accounting. One type of user profile is a daily limite of 30 minutes. Sometimes I find accounting records with a session time of 2147483647 seconds. This stops the 30 minutes users immediately. This happens 1 to 5 times per day.
Further I found out that pfsense sense is sending the accouting time to freeradius.
To analyse the problem I entered a piece of code into the function RADIUS_ACCOUNTING_STOP (in radius_accounting.inc) to log large or negative values.
Code:
/* Log large Session time by Erik */
if ($session_time > 300000 or $session_time < 0) {
$f_handle = fopen("/tmp/larg_ses_time_debug.log","a");
$log = date("Y.m.d H:i:s")." / Session time: ".$session_time." / Start-time: ".$start_time." / Stop-time: ".$stop_time." / IP: ".$clientip." \n";
fwrite($f_handle, $log);
fclose($f_handle);
}
The result of the log from 03/12/2012 is:
2012.12.03 19:03:21 / Session time: -12949 / Start-time: 1354557800 / Stop-time: 1354544851 / IP: 172.20.229.56
2012.12.03 19:05:24 / Session time: -13068 / Start-time: 1354557919 / Stop-time: 1354544851 / IP: 172.20.229.64
Negative value is logic because the attribute sessiontime is an integer which switches to 2147483647 with a negative sign.
How can this happen that start time is higher then stop time?
First I thought that the update comes before start radius. But the session time difference is too high. This could be if the differnce would be < 60 seconds.
I patch a hotfix not to account negative values. But this can't be the proper solution.
Updated by Erik Ruedin over 11 years ago
Hello,
Has anybody an idea what could the reason be? I installed the version 2.0.2 and it's worse. This error provokes in idle-timeout just after login. My patch in file radius_account.php in function radiu_accounting_stop helps avoiding large session time but it doesn't stop idle-timeout.
Has erverybode the same issue? Is there a solution to fix this issue?
I suppose that prune_old process is earlier or parallel to the radius start process. It happens only just after login. This is an assumption only.
Updated by Erik Ruedin about 11 years ago
This issue isn't solved with 2.0.3
With each release I have to modify the function "RADIUS_ACCOUNTING_STOP" in file "radius_accounting.inc" a piece of code to avoid an unwanted idle-timeout.
if ($session_time < 0) {
$f_handle = fopen("/tmp/larg_ses_time_debug.log","a");
$log = date("Y.m.d H:i:s")." / Session time: ".$session_time." / Start-time: ".$start_time." / Stop-time: ".$stop_time." / IP: ".$clientip." / Term Clause: ".$term_cause." /Interim: ".$interimupdate." \n";
fwrite($f_handle, $log);
fclose($f_handle);
$session_time = 0;
}
Isn't there an idea why sometimes $session-time is set to 2147483647 seconds (=maximal value of long integer variable).
Updated by A FL almost 6 years ago
Hi,
I think the root cause of this issue was captiveportal that was sending the wrong stop-time to RADIUS_ACCOUNTING_STOP()
It may have been solved years ago in https://github.com/pfsense/pfsense/pull/2487
This would mean that this issue only happened when multiple users were connected, and idle-timeout was set
Could anyone confirm that the issue doesn't exist anymore? I didn't arrived to reproduce this but I guess it need some testing.
Updated by A FL almost 6 years ago
@Jim P : would it be possible to have access to any old 2.0.1 ISO for testing?
I didn’t arrived to find one on internet, and https://nyifiles.pfsense.org/mirror/downloads/old/ is 403 forbidden..
Updated by Jim Pingle almost 6 years ago
- Status changed from New to Resolved
Since the old releases were insecure and there wasn't much reason to keep them available, we locked those down to prevent users from knowingly installing a vulnerable version of pfSense.
There shouldn't be a need to actually load the older versions. Nobody has commented on this ticket for 5 years, odds are it was fixed long ago and the fix was never associated with this ticket, or this was a duplicate that wasn't known about at the time.
If you can't reproduce it, and nobody else has complained in the last 5 years, it's safe to assume it is no longer a problem until proven otherwise.