Bug #4652
closedCaptive Portal Idle-Timeout causes 2147483647 for acctsessiontime when no data transferred
100%
Updated by Markus Tellian over 9 years ago
If you log in to captive portal and a Idle-Timeout is set (in my setup from radius)
the function captiveportal_get_last_activity() in captiveportal.inc returns a random unix date if the client did not consumed any data.
This value in $lastact causes an error in a date calculation.
The solution is to check if the client consumed data yet. If we return 0 the time is set correctly in the past code.
I wrote a simple bugfix:
//file: /etc/inc/captiveportal.inc
// get last activity timestamp given client IP address function captiveportal_get_last_activity($ip, $mac = NULL, $table = 2) { global $cpzoneid; $ipfw_tbl1 = pfSense_ipfw_getTablestats($cpzoneid, IP_FW_TABLE_XLISTENTRY, 1, $ip, $mac); //get data from table1 download $ipfw_tbl2 = pfSense_ipfw_getTablestats($cpzoneid, IP_FW_TABLE_XLISTENTRY, 2, $ip, $mac); //get data from table1 upload //BUGFIX if (is_array($ipfw_tbl1)) { if ($ipfw_tbl1['packets'] > 0) { //if packets sent, timestamp is correct return $ipfwoutput['timestamp']; } else { //if no packets sent, return 0 to avoid fals time by bugfunction pfSense_ipfw_getTablestats openlog("logportalauth", LOG_PID, LOG_LOCAL4); syslog(LOG_INFO, "BUG AVOIDED table1"); closelog(); return 0; } } if (is_array($ipfw_tbl2)) { if ($ipfw_tbl2['packets'] > 0) { //if packets sent, timestamp is correct return $ipfwoutput['timestamp']; } else { //if no packets sent, return 0 to avoid fals time by bugfunction pfSense_ipfw_getTablestats openlog("logportalauth", LOG_PID, LOG_LOCAL4); syslog(LOG_INFO, "BUG AVOIDED table2"); closelog(); return 0; } } return 0; }
Updated by Markus Tellian over 9 years ago
Accidentally I posted the code from my dev PfSense, here is the working code:
/* get last activity timestamp given client IP address */ function captiveportal_get_last_activity($ip, $mac = NULL, $table = 2) { global $cpzoneid; $ipfw_tbl1 = pfSense_ipfw_getTablestats($cpzoneid, IP_FW_TABLE_XLISTENTRY, 1, $ip, $mac); //get data from table1 download $ipfw_tbl2 = pfSense_ipfw_getTablestats($cpzoneid, IP_FW_TABLE_XLISTENTRY, 2, $ip, $mac); //get data from table1 upload //BUGFIX if (is_array($ipfw_tbl1)) { if ($ipfw_tbl1['packets'] > 0) { //if packets sent, timestamp is correct return $ipfw_tbl1['timestamp']; } else { //if no packets sent, return 0 to avoid fals time by bugfunction pfSense_ipfw_getTablestats return 0; } } if (is_array($ipfw_tbl2)) { if ($ipfw_tbl2['packets'] > 0) { //if packets sent, timestamp is correct return $ipfw_tbl2['timestamp']; } else { //if no packets sent, return 0 to avoid fals time by bugfunction pfSense_ipfw_getTablestats return 0; } } return 0; }
Updated by Ermal Luçi over 9 years ago
- % Done changed from 0 to 100
Applied in changeset 2842c8d407e34a9183908a1677ec162a7b0ea209.
Updated by Ermal Luçi over 9 years ago
Applied in changeset 120acbae8c2edd2e60685dd7ca16966cd988afc7.
Updated by Markus Tellian over 9 years ago
The change applied in 120acbae8c2edd2e60685dd7ca16966cd988afc7
only reads the output table for bytes.
I have not tested it yet and download without upload should probably never happen in a normal use scenario but it will still cause the related error.
Updated by Markus Tellian over 9 years ago
Markus Tellian wrote:
The change applied in 120acbae8c2edd2e60685dd7ca16966cd988afc7
only reads the output table for bytes.
I have not tested it yet and download without upload should probably never happen in a normal use scenario but then it will still cause the related error.
Updated by Chris Buechler about 9 years ago
- Subject changed from Captive Portal Idle-Timeout causes 2147483647 for acctsessiontime to Captive Portal Idle-Timeout causes 2147483647 for acctsessiontime when no data transferred
- Status changed from Feedback to Resolved
- Affected Version changed from 2.2.1 to 2.2.x
- Affected Architecture added
- Affected Architecture deleted (
amd64)
works from what I can tell. Markus, if you can see any remaining issues here in 2.2.3, please follow up.