pfSense

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;
}

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;
}

Applied in changeset 120acbae8c2edd2e60685dd7ca16966cd988afc7.

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.

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.