Project

General

Profile

Actions

Bug #4652

closed

Captive Portal Idle-Timeout causes 2147483647 for acctsessiontime when no data transferred

Added by Markus Tellian over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Category:
Captive Portal
Target version:
Start date:
04/24/2015
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.x
Affected Architecture:
Actions #1

Updated by Markus Tellian over 6 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;
}

Actions #2

Updated by Markus Tellian over 6 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;
}
Actions #3

Updated by Ermal Luçi over 6 years ago

  • Status changed from New to Feedback

Committed.

Actions #4

Updated by Ermal Luçi over 6 years ago

  • % Done changed from 0 to 100
Actions #5

Updated by Ermal Luçi over 6 years ago

Actions #6

Updated by Markus Tellian over 6 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.

Actions #7

Updated by Markus Tellian over 6 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.

Actions #8

Updated by Chris Buechler over 6 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.

Actions

Also available in: Atom PDF