Project

General

Profile

Actions

Bug #2710

closed

Captive Portal radius accounting negative session time

Added by Erik Ruedin over 11 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
-
Start date:
12/04/2012
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0.1
Affected Architecture:
amd64

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.

Actions

Also available in: Atom PDF