Captive portal logouts



  • Hi,

    Have just reinstalled a server from an early 2.0 Alpha-alpha version to 2.0-RC3 (June 21st build) that is providing a captive portal.  Everything was working perfectly and was a huge improvement from the alpha-alpha version where the portal login page would fail to appear regularly etc.

    I've just done an auto-update to July 4th snapshot and now I'm finding my portal clients are being logged out after a few seconds.  The idle timeout is set to 120 mins, with hard timeout set to 420.

    Restarting the captive portal service makes no difference - here's the portal authentication logs:

    Jul 8 09:57:01 	logportalauth[21921]: LOGIN: testuser, , 10.5.192.14
    Jul 8 09:57:32 	logportalauth[14166]: TIMEOUT: testuser, , 10.5.192.14
    Jul 8 10:01:42 	logportalauth[21921]: LOGIN: testuser, , 10.5.192.14
    Jul 8 10:02:34 	logportalauth[10568]: TIMEOUT: testuser, , 10.5.192.14
    Jul 8 10:09:56 	logportalauth[19176]: LOGIN: testuser, , 10.5.192.14
    Jul 8 10:10:35 	logportalauth[41891]: TIMEOUT: testuser, , 10.5.192.14
    Jul 8 10:24:07 	logportalauth[63680]: Restarting captive portal.
    Jul 8 10:24:18 	logportalauth[63358]: Restarting captive portal.
    Jul 8 10:26:00 	logportalauth[20421]: LOGIN: testuser, , 10.5.192.14
    Jul 8 10:26:19 	logportalauth[15393]: TIMEOUT: testuser, , 10.5.192.14
    

    Anyone got any ideas?

    Thanks,
    Stuart



  • Upgrade to latest snapshot the issue has been fixed.



  • @ermal:

    Upgrade to latest snapshot the issue has been fixed.

    Thanks - I actually saw the sticky thread about using the RELENG snapshots after I had posted.  At the time, I was under the impression that I was on the latest version at the time, but am now running the snapshot from yesterday.

    Fingers crossed, everything is looking good at the moment.

    Regards,
    Stuart



  • Stupots, if you want to see the bug report for this issue, take a look at : http://redmine.pfsense.org/issues/1653

    A patch that adds the functionality to report an ip address's last activity timestamp was left out of the build.  So idle timeouts always took effect immediately.
    Josh


Log in to reply