Can user sessions persist after reboot?

  • Our CP is only showing a usage page, once after user logs on with his RADIUS credentials.
    Now there are reasonable users logged on and everything works like a charm.
    But i wonder what would happen on reboot (e.g. in case of an software-update). Will the session be all lost, so that they are presented the usage-page again?

  • Does'nt anybody know what happens after reboot? and how i persist this situation?

  • Hi.

    You're afraid to reboot ?
    Do so - the same will happen when the power goes down anyway. And tel us what happened ;)

    I just discovered that stopping the captive portal ( Status: Services ) and then starting it again will NOT loose connected users …

  • @Gertjan:

    I just discovered that stopping the captive portal ( Status: Services ) and then starting it again will NOT loose connected users …

    Just a quick word of warning - this is only the case in the more recent released of PFS. If you're running an older version - pre-2.2.x or thereabouts - you may well find a restart of the captive portal service will flush your currently authenticated users. I used to avoid restarting the CP myself for this very reason, but found that the latest release kept my sessions after restart.

  • I'm running at 2.2.5-RELEASE.

    Well, after reading some of the sources, i found that CP uses Sqlite3 databases which reside under /var/db/ and named using this rule "captiveportal<name_of_cp>.db".
    You can easily view the contents by logging in via the remote-console (ssh) go into the shell (option "8" in the menu) and issue the following command:

    sqlite3 captiveportalwlan_sd.db "SELECT * FROM captiveportal"

    and you will get results like these:


    This is the schema of the db:

    sqlite3 captiveportalwlan_sd.db ".schem captiveportal"

    which will give you:

    CREATE TABLE captiveportal (allow_time INTEGER, pipeno INTEGER, ip TEXT, mac TEXT, username TEXT, sessionid TEXT, bpassword TEXT, session_timeout INTEGER, idle_timeout INTEGER, session_terminate_time INTEGER, interim_interval INTEGER, radiusctx TEXT);
    CREATE UNIQUE INDEX idx_active ON captiveportal (sessionid, username);
    CREATE INDEX user ON captiveportal (username);
    CREATE INDEX ip ON captiveportal (ip);
    CREATE INDEX starttime ON captiveportal (allow_time);

    I found the piece of code which loads the contents of this db at runtime. So there is a great chance that this DBs will survive a reboot and their contents will not get erased but reused.
    But i will test this on another instance first.</name_of_cp>

  • ;D

    All this, and more, is actually easy to find if your 'read' /etc/inc/captiveportal.php

    You will even find this: (this is the 2.2.7 dev version - and the same as 2.2.6) :
    Read it like this:

    If Captive portal enbaled
     If Booting
       then delete the database file .....

    Also : a nasty bug was found when opening and managing the "sqlite3" database - this was one of the reasons why "2.2.5-Release" is ancient now, and that 2.2.6 came out ;)

    Reading /etc/inc/captiveportal.php will show you that other files exist (in the same /var/db dir) : captiveportaldn.rules and captiveportal_<name_of_cp>.rules
    These two files ARE deleted when the captive portal starts up.
    These two files are NOT used to (re) preset the firewall after booting.</name_of_cp>

Log in to reply