Wrong last activity for some users



  • Hi, I am using 2.1.3 and have strange issue with captive portal

    I am trying to use idle and hard timeout options but somehow captiveportal reads the last activity value faulty for one or more users(not all of them)

    because of it these users are kicked out repeatedly, Can anyone help please



  • Hi there.

    Use this basic debugging tric:
    Open /etc/inc/captiveportal.inc

    Search

    function captiveportal_prune_old()
    

    In this function most (if not all) time house hold keeping is handled.

    It's called 'by Magic' every 60 secondes.

    Insert this line arround line 600:

    captiveportal_logportalauth("function captiveportal_prune_old() called","","","");
    

    Now, check your Portal log ….
    The line pops up every 60 secondes ?

    If so, continue ..... time stuff is dealt with a couple of line later. Through all interesseting decissions to the log.



  • @Gertjan:

    Hi there.

    Use this basic debugging tric:
    Open /etc/inc/captiveportal.inc

    Search

    function captiveportal_prune_old()
    

    In this function most (if not all) time house hold keeping is handled.

    It's called 'by Magic' every 60 secondes.

    Insert this line arround line 600:

    captiveportal_logportalauth("function captiveportal_prune_old() called","","","");
    

    Now, check your Portal log ….
    The line pops up every 60 secondes ?

    If so, continue ..... time stuff is dealt with a couple of line later. Through all interesseting decissions to the log.

    thanks for the answer but, I could not understand what has extra lines in portalauth.log got to do with the problem, will it correct the misdedected last activity time? or is it just to check if prune_old is called or not every 60 seconds

    I was thinking to add a code peace to check if the $lastact time is bigger then the $cpentry[0] (which is session start time),
    this way the wrong last activity values will be ignored



  • Yes for the 60 sec check.

    function captiveportal_prune_old() is doing the 'time' house keeping.
    So, better check if its actually run every 60 sec first (this was ones a problem).

    Next, as you said, using the same log function to detail your situation (radius, vouchers, user login, whatever …)

    edit: the fact that $cpentry[0] (which is session start time) is BIGGER then $lastact is indeed a strange situation.
    Ones the session established, $cpentry[0] should never change - $lastact should follow the current time, if user is still active.



  • if ($lastact && $lastact >= $cpentry[0] && (($pruning_time - $lastact) >= $uidletimeout)) {
    $timedout = true;
    $term_cause = 4; // Idle-Timeout
    $stop_time = $lastact; // Entry added to comply with WISPr
    }

    ı have added the code piece in red, this checks if lastact is bigger than session start and if not does nothing, I mean no kick out