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

    PfSense 2.1 Captive Portal RADIUS Accouting records not sent to RADIUS Server

    Scheduled Pinned Locked Moved Captive Portal
    11 Posts 5 Posters 3.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
      communig8
      last edited by

      I have a number of pfSense Servers running pfSense 2.0.1, 2.0.3 and 2.1 all using an external RADIUS Server for authentication and accounting.
      In fact, all using the same RADIUS Server.
      The 2.0.x pfSense Servers are working fine and send RADIUS accounting data to the RADIUS Server.
      However, I have 2 x pfSense 2.1 that are both suffering the same problem.
      After a user completes has logged in an initial accounting record is sent to the RADIUS Server (radacct table) but that's it, no more are sent.
      A packet capture on the pfSense server shows this. This leaves the users acctstoptime null in radacct.
      If the user is timed out of disconnected via CP Status, still no accounting data.
      But if I disable the CP service, all the records are updated but with the current date/time.
      I have also found that data usage counts are not sent either.
      I know pfSense 2.1 has had a lot of changes to CP but has something been broken along the way?
      I also get this problem on a fresh install. I get this with interim and start/stop accounting.
      Anyone else found this? Found a fix or even seen this reported before?
      Thanks, Richard

      Signatures are a sign of having signatures.

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

        Had a look through the code in /etc/inc/captiveportal.inc and in various places the code testes the $config array for 'radacct_enable'.
        Even through "send RADIUS accounting packets" is checked 'radacct_enable' is empty so the code thinks RADIUS accounting is inactive.

        Signatures are a sign of having signatures.

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

          On even more investigation, code in /etc/inc/cativeportal.inc is referring to the wrong columns in the array returned by captiveportal_read_db().
          For example in captiveportal_disconnect_client() column 10 is being used to find the RADIUS server to use but its actually in column 9.
          Changing the column reference to 9 causes the correct data to be sent to RADIUS in the event of a DISCONNECT.

          Signatures are a sign of having signatures.

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

            Raised bug 3447 on Redmine.

            Signatures are a sign of having signatures.

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

              Changing to code in captiveportal_disconnect_client() to use column 9 was a bit of a fluke as that column just happened to be null.
              Looking at the code in captiveportal_opendb() which contains the CREATE for the table, there is no information on the RADIUS server to use.
              So I don't know what's going on in captiveportal_disconnect_client() and other places in /etc/inc/cativeportal.inc to locate the correct RADIUS server.

              Signatures are a sign of having signatures.

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

                I've created a local version of captiveportal.inc (attached as captiveportal.txt) to replace /etc/inc/captiveportal.inc (use at your own riaks!!).
                This "fixed" the following functions that are using an incorrect RADIUS server lists.

                captiveportal_prune_old()
                captiveportal_disconnect()
                captiveportal_radius_stop_all()
                portal_allow()

                This "fix" only supports a RADIUS Primary Authentication Source.
                I needed this until the good people a pfSense do a proper fix.

                Richard

                captiveportal.txt

                Signatures are a sign of having signatures.

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

                  I fixed in for good on 2.1 repo.

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

                    I thought it was targeted for 2.1.1 ?

                    Signatures are a sign of having signatures.

                    1 Reply Last reply Reply Quote 0
                    • F
                      fsantaana
                      last edited by

                      Hello,

                      I am having this same issue on the 2.2 Release version. The exact same is happening when only the first login is being sent to the radacct table.

                      1 Reply Last reply Reply Quote 0
                      • U
                        unixaccent
                        last edited by

                        Same problem here. Anyone who has fixed this? I am using 2.2.1. Thank you.

                        1 Reply Last reply Reply Quote 0
                        • V
                          vitord2
                          last edited by

                          Same problem on 2.2.2. Empty radacct table

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