Project

General

Profile

Bug #4652

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

Added by Markus Tellian about 4 years ago. Updated about 4 years ago.

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

100%

Estimated time:
Affected Version:
2.2.x
Affected Architecture:

Associated revisions

Revision 2842c8d4 (diff)
Added by Ermal Luçi about 4 years ago

Fixes #4652 put workaround for bogus timestamp until real data are cosnumed.

Revision 120acbae (diff)
Added by Ermal Luçi about 4 years ago

Fixes #4652 put workaround for bogus timestamp until real data are cosnumed.

Revision be754c8b (diff)
Added by Ermal Luçi about 4 years ago

Ticket #4652 actually return value as expected!

Revision 3ce84694 (diff)
Added by Ermal Luçi about 4 years ago

Ticket #4652 actually return value as expected!

History

#1 Updated by Markus Tellian about 4 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;
}

#2 Updated by Markus Tellian about 4 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;
}

#3 Updated by Ermal Luçi about 4 years ago

  • Status changed from New to Feedback

Committed.

#4 Updated by Ermal Luçi about 4 years ago

  • % Done changed from 0 to 100

#5 Updated by Ermal Luçi about 4 years ago

#6 Updated by Markus Tellian about 4 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.

#7 Updated by Markus Tellian about 4 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.

#8 Updated by Chris Buechler about 4 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 deleted (amd64)

works from what I can tell. Markus, if you can see any remaining issues here in 2.2.3, please follow up.

Also available in: Atom PDF