Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Possible solution for delayed termination of captive portal users/clients

    Scheduled Pinned Locked Moved Captive Portal
    9 Posts 4 Posters 4.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      cruzades
      last edited by

      given

      captive portal user id: wifi
      usage limit: 1 day or 24hrs will due on 00:01AM
      idle timeout: 3hrs
      hard timeout: 0

      here is the problem

      If user wifi still connected until 00:01AM (which supposedly he will be disconnected automatically) he won't be disconnected until he logs out or he reaches the idle timeout.

      possible solution is to edit the freeradius.inc in such a way it will look for users that expire on captive database and delete that entry right away.

      i'm calling the coders, will this be possible or it is fixed on version 2.0 already?

      any thoughts?

      1 Reply Last reply Reply Quote 0
      • C
        cordeos
        last edited by

        We adapted the the existing 'Prune' routine, threw it into a seperate php file and call it from a Cron job (every 30minutes) using following command:

        /usr/local/bin/php -q /usr/local/captiveportal/portal-reauth.php

        So what it does is run though the local file created by cp (of all current users) and does a re-auth call to radius to see if they should still be logged in. Given we allow concurrency on the system we have to send an accounting disconnect then reconnect after (just the way we have things setup)

        Have attached the PHP page we created to this post. Note it is setup for concurrency at the moment - maybe you dont need that. Hopefully work out of the box for you. (remove the txt extension)

        Hope this helps - not sure if its what your after ?

        portal-reauth.php.txt

        1 Reply Last reply Reply Quote 0
        • C
          cordeos
          last edited by

          Ob btw - this is for 1.2.3

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by

            You have an option to reauthenticate users on the CP no need for this hack.

            1 Reply Last reply Reply Quote 0
            • J
              joe_adk
              last edited by

              Doesn't the "reauthenticate" run every minute? Everyone always says, "don't use it".

              1 Reply Last reply Reply Quote 0
              • C
                cordeos
                last edited by

                Yeah - we read the forums and didnt like the sound of a reauthenticate every minute. Too much loading we thought. Yes this hack is not ideal, but gets around this problem. In 2.0 can you specify the reauthenticate interval ? that would be great.

                1 Reply Last reply Reply Quote 0
                • C
                  cruzades
                  last edited by

                  @cordeos:

                  We adapted the the existing 'Prune' routine, threw it into a seperate php file and call it from a Cron job (every 30minutes) using following command:

                  /usr/local/bin/php -q /usr/local/captiveportal/portal-reauth.php

                  So what it does is run though the local file created by cp (of all current users) and does a re-auth call to radius to see if they should still be logged in. Given we allow concurrency on the system we have to send an accounting disconnect then reconnect after (just the way we have things setup)

                  Have attached the PHP page we created to this post. Note it is setup for concurrency at the moment - maybe you dont need that. Hopefully work out of the box for you. (remove the txt extension)

                  Hope this helps - not sure if its what your after ?

                  sir, I'm too noob about scripting, I would like to know if this could be adjusted from 30minute to a specific time (e.g. 0000hrs)?, so that all connected cp users needs to re-authenticate, and hopefully the due accounts will not.

                  btw, I'm using freeRadius for authentication.

                  thanks.

                  1 Reply Last reply Reply Quote 0
                  • C
                    cordeos
                    last edited by

                    Yes sure - this can. Its actually just a matter of setting the time the script runs. You can run it every 30 minutes, or at one specific time - all depends on how you setup the cron job.

                    e.g.
                    0  1  *  *  *  root  /usr/local/bin/php -q /usr/local/captiveportal/portal-reauth.php

                    would run every day at 1am. You should do a google on cron jobs syntax to understand how to set the time and frequency etc.

                    Sorry - I should mention that this should be used at your own risk as is an adaptation (hack) from stock pfsense. But it works for us well.

                    1 Reply Last reply Reply Quote 0
                    • C
                      cruzades
                      last edited by

                      thank you sir.

                      sir, may also ask a minor clarification with the "concurrency" you've just mentioned, is this means that this will "only" work if I had put "checked" on "Disable concurrent logins"?

                      oh, how if I would like to stop using it or remove it from running? how will I do it?

                      
                      /* no pruning for fixed mac address entry */
                      		if (portal_mac_fixed($cpdb[$i][3])) 
                      

                      based on your code, what do you mean "fixed mac address", is this the Pass-through entries?

                      -cruzades
                      still researching/learning how to use cron job :)

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.