New session doesn't create unique Acct-Session-Id
-
Hi all, CP is setup with an external freeradius server with accounting enabled and works great.
When I reboot PF with
Preserve users database
enabled the CP sendsAccounting-Off
to radius (which stops all the radius user sessions and doesn't log out users on the CP)The issue shows up on the next account interim update sent to radius. The CP still uses the pre-reboot
Acct-Session-Id
so it is updating the old session and overwriting everything in the radacct table rather than using a new ID where radius logic will know to create a new table in radacct.I would think this is unwanted, and the session is new so should use a new ID.
I'll look at a workaround for now but any ideas on whether PF would look to fix this? -
It turns out that the CP radius client isn't doing the right thing but good ole freeradius can fix it.
I managed to alter the Freeradius database update when it receives the accounting_off packet to create a unique ID. Now the next interim update creates a new session as it should.
-
@guntery said in New session doesn't create unique Acct-Session-Id:
When I reboot PF with Preserve users database enabled the CP sends Accounting-Off
I can't re test right now, but :
When you shut down pfSense, it will iterate over the connected users list (== the pfSense internal connected database) and send for every connected user a "Accounting-Off" event to Radius.
So far, so good.
The database contains all the login credentials (name, password, MAC, IP, whatever).
When pfSense boots, and the captive portal starts, and the option "Preserve users database" is activated, and the database file is readable and contains valid data, then, for every entry, a "Accounting-On" (or login, or whatever) event is send to Radius. I guess a series of automated logins takes place.You might have a point with the old / new session IDs.
Ages ago I created a cron :<?php try { $link = new PDO('mysql:host=192.168.1.33;port=3307;dbname=radius', 'radius', 'xxxxx'); // Check connection if($link === false) { die("ERROR: Could not connect."); } // Attempt delete query execution $sql = "DELETE FROM `radacct` WHERE `acctstoptime` IS NULL and `acctstarttime` < (NOW() - INTERVAL 610 MINUTE)"; $stmt = $link->prepare($sql); $stmt->execute(); unset($stmt); } catch (PDOException $e) { print "Error!: " . $e->getMessage() . "<br/>"; die(); } ?>
This script deletes 'stale' ( ?) entries from the radacct table, created in the last 610 minutes.
This script is still running today. I should test what it does ( I forgot the why part), and if it's still needed. maybe it's related to your question.This should work well, of course.
But normally, why rebooting pfSense ? Disrupting portal users connection is bad for your health.
My pfSense 'never' reboots.@guntery said in New session doesn't create unique Acct-Session-Id:
I managed to alter the Freeradius database update when it receives the accounting_off packet to create a unique ID
Can you document that and past it here ?
-
I wanted to test all reasons for the sessions to go stale or how it might make a mess of the radacct tables if something went wrong.
This is what the CP sends on off/on
Thu Apr 28 07:07:26 2022 Service-Type = Login-User Acct-Status-Type = Accounting-On Acct-Authentic = RADIUS NAS-IP-Address = 10.1.1.1 NAS-Identifier = "test" Called-Station-Id = "pfSense-test.home.arpa" Acct-Unique-Session-Id = "2f044961d1383ddc" Timestamp = 1651129646
Freeradius has this query built in which closes all user sessions from that NASID:
accounting_onoff_query = "\ UPDATE ${acct_table1} \ SET \ acctstoptime = '%S', \ acctsessiontime = unix_timestamp('%S') - \ unix_timestamp(acctstarttime), \ acctterminatecause = 'stale', \ acctsessionid = '%{Acct-Unique-Session-Id}xxx', \ acctuniqueid = '%{Acct-Unique-Session-Id}zzz', \ acctstopdelay = %{%{Acct-Delay-Time}:-0} \ WHERE acctstoptime IS NULL \ AND nasipaddress = '%{NAS-IP-Address}' \ AND NASIdentifier = 'test' \ AND acctstarttime <= '%S'"
I added the
{Acct-Unique-Session-Id}xxx
to ensure that session isn't used again.Yep, we use a few scripts to clean up the sessions depending on how often and correctly the NAS updates radacct.
-
oh my logic was poor - all the users sessions will have that same 'unique' ID.
Not sure it matters though.