Freeradius - radacct session issue
Hi Issue: I am picking a lot of entries in radacct that seem to have been updated days after session has been closed (recording of the timestamp of an accounting stop reception). Such an entry is looking like: select * from radacct where radacctid = 7299616\G *************************** 1. row *************************** radacctid: 7299616 acctsessionid: f0766fb97a76.0400.dhcp acctuniqueid: 9c83f2fc9f88007e5ebaf552233b6817 username: xxxxxx groupname: realm: xxxxxxxx nasipaddress: 10.100.2.10 nasidentifier: bgate1030 nasportid: slot=3D3D0=3D3B nasporttype: Wireless-802.11 acctstarttime: 2018-02-22 16:50:02 acctupdatetime: 2018-03-06 01:30:51 acctstoptime: 2018-02-25 18:55:30 acctinterval: 900 acctsessiontime: 6301 acctauthentic: connectinfo_start: connectinfo_stop: acctinputoctets: 359928391 acctoutputoctets: 6626058 calledstationid: A6-74-2A-B0-D2-4C:xxxxxxxx callingstationid: F0-76-6F-B9-7A-76 acctterminatecause: NAS-Reboot servicetype: framedprotocol: framedipaddress: 10.16.59.137 acctstartdelay: NULL acctstopdelay: NULL xascendsessionsvrkey: NULL 1 row in set (0.01 sec) select * from radacct where radacctid = 4605678\G *************************** 1. row *************************** radacctid: 4605678 acctsessionid: 2400ba1bcd17.0400.dhcp acctuniqueid: 3590303eebf7e0a3dbdca9116f37a6a2 username: xxxxxx groupname: realm: xxxxxxxxxxxx nasipaddress: 10.100.2.10 nasidentifier: bgate1030 nasportid: slot=3D3D0=3D3B nasporttype: Wireless-802.11 acctstarttime: 2018-01-18 09:11:03 acctupdatetime: 2018-03-09 16:10:37 acctstoptime: 2018-01-18 06:17:36 acctinterval: 10681 acctsessiontime: 942 acctauthentic: connectinfo_start: connectinfo_stop: acctinputoctets: 1716210 acctoutputoctets: 601621 calledstationid: A6-74-2A-AD-F0-F3:xxxxxxx callingstationid: 24-00-BA-1B-CD-17 acctterminatecause: NAS-Request servicetype: framedprotocol: framedipaddress: 10.16.22.228 acctstartdelay: NULL acctstopdelay: NULL xascendsessionsvrkey: NULL 1 row in set (0.00 sec) select * from radacct where radacctid = 5016371\G *************************** 1. row *************************** radacctid: 5016371 acctsessionid: a04c5b6485b1.0400.dhcp acctuniqueid: f28f3633c6d406e3d68d9bf75f1f3d71 username: xxxxxxxxxx groupname: realm: xxxxxxxxx nasipaddress: 10.100.2.10 nasidentifier: bgate1030 nasportid: slot=3D3D0=3D3B nasporttype: Wireless-802.11 acctstarttime: 2018-01-15 10:44:44 acctupdatetime: 2018-03-01 12:02:54 acctstoptime: 2018-01-15 12:06:12 acctinterval: 900 acctsessiontime: 1826 acctauthentic: connectinfo_start: connectinfo_stop: acctinputoctets: 120903 acctoutputoctets: 63363 calledstationid: B6-74-2A-AD-EF-A5:xxxxxxxxxx callingstationid: A0-4C-5B-64-85-B1 acctterminatecause: NAS-Request servicetype: framedprotocol: framedipaddress: 10.16.21.160 acctstartdelay: NULL acctstopdelay: NULL xascendsessionsvrkey: NULL 1 row in set (0.01 sec) Context: Freeradius (Version 3.0.13 see below) is deployed with a front-end called Radiusdesk. Service is provided thru WiFi APs centrally managed (Capwap) by and Access Controller (AC) acting as Freeradius client. This AC is regularly performing unattended reboots, hence most likely the replication of Accounting Session Id. The Accounting SQL management is performed via the standard Freeradius sql module. We picked up the issue when we identified some discrepancies in collecting user usage stats. Any idea why Freeradius would overwrite an entry that has been "closed"? and how we could work around that (beside ditching the AC or systematically moving the "closed" entries to another table upon reception of Acct_Stop)? radiusd: FreeRADIUS Version 3.0.13 (git #d5a382e), for host x86_64-pc-linux-gnu, built on Mar 24 2017 at 19:26:35 FreeRADIUS Version 3.0.13 Copyright (C) 1999-2017 The FreeRADIUS server project and contributors There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License For more information about these matters, see the file named COPYRIGHT PLM -- Disclaimer and Confidentiality Warning - This message is intended for the addressee only. If you are not the intended recipient of this message, you are notified that any distribution, use of or copying of this communication is strictly prohibited. If you have received the communication in error, please notify the sender immediately. The views and opinions expressed in this message are those of the individual sender of this message and do not necessarily represent the views and opinions of Brightwave Technologies Consequently, Brightwave Technologies does not accept responsibility for such views and opinions and this message should not be read as representing the views and opinions of Brightwave Technologies without subsequent written confirmation. Each page attached hereto must also be read in conjunction with this disclaimer.
On Mar 9, 2018, at 9:37 AM, Pierre Delamotte <pierre.delamotte@brightwave.co.za> wrote:
Issue: I am picking a lot of entries in radacct that seem to have been updated days after session has been closed (recording of the timestamp of an accounting stop reception).
FreeRADIUS only logs what it receives. It doesn't invent accounting records. If a record is logged days after a session was closed, it's because the NAS sent an accounting packet days after that session was closed.
Context: Freeradius (Version 3.0.13 see below) is deployed with a front-end called Radiusdesk. Service is provided thru WiFi APs centrally managed (Capwap) by and Access Controller (AC) acting as Freeradius client.
This AC is regularly performing unattended reboots, hence most likely the replication of Accounting Session Id.
Ah... the NAS is broken, then. It should NOT re-use Acct-Session-ID. It's 2018 for crying out loud... there's just no excuse for shitty software.
Any idea why Freeradius would overwrite an entry that has been "closed"?
If the NAS is lying to the server and re-using Acct-Session-ID, it's difficult. Tho FreeRADIUS adds Acct-Unique-Session-Id in order to deal with these issues. i.e. the default queries in v3 key off of Acct-Unique-Session-ID where possible, instead of Acct-Session-Id.
and how we could work around that (beside ditching the AC or systematically moving the "closed" entries to another table upon reception of Acct_Stop)?
The queries in v3 *should* take care of dealing with normal situations. But... if your NAS is broken, moving records to a different table may be a good solution. That, or throwing the crappy NAS in he garbage, and buying one one that works correctly. Alan DeKok.
Hi Alan Thank you for answering Agreed that the NAS is crappy, but ditching it is not an option for the moment (it is one of my main Capwap controller), so I have to leave with it. Knowing that at least the NAS is signalling Freeradius when it is rebooting, could I consider the option of updating a radacct record acctuniqueid (I see that the field is defined as Unique Key NOT NULL) targeted by a stop by setting the value to NULL? What I expect from that is that Freeradius will create a new radacct record upon reception of a new accounting packet carrying the same "Accounting Id". Basically: - I remove the NOT NULL constraint on acctuniqueid field in radacct table definition - I store NULL in the field upon receiving a stop Should I expect bad side effects? Best regards Pierre On Fri, Mar 9, 2018 at 4:50 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 9, 2018, at 9:37 AM, Pierre Delamotte <pierre.delamotte@brightwave. co.za> wrote:
Issue: I am picking a lot of entries in radacct that seem to have been updated days after session has been closed (recording of the timestamp of an accounting stop reception).
FreeRADIUS only logs what it receives. It doesn't invent accounting records.
If a record is logged days after a session was closed, it's because the NAS sent an accounting packet days after that session was closed.
Context: Freeradius (Version 3.0.13 see below) is deployed with a front-end called Radiusdesk. Service is provided thru WiFi APs centrally managed (Capwap) by and Access Controller (AC) acting as Freeradius client.
This AC is regularly performing unattended reboots, hence most likely the replication of Accounting Session Id.
Ah... the NAS is broken, then. It should NOT re-use Acct-Session-ID. It's 2018 for crying out loud... there's just no excuse for shitty software.
Any idea why Freeradius would overwrite an entry that has been "closed"?
If the NAS is lying to the server and re-using Acct-Session-ID, it's difficult. Tho FreeRADIUS adds Acct-Unique-Session-Id in order to deal with these issues.
i.e. the default queries in v3 key off of Acct-Unique-Session-ID where possible, instead of Acct-Session-Id.
and how we could work around that (beside ditching the AC or systematically moving the "closed" entries to another table upon reception of Acct_Stop)?
The queries in v3 *should* take care of dealing with normal situations.
But... if your NAS is broken, moving records to a different table may be a good solution.
That, or throwing the crappy NAS in he garbage, and buying one one that works correctly.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- *Pierre de La Motte* *CTO* *Tel: *+27 10 330 0904 *Cell:* +27 82 375 0607 *Email:* pierre.delamotte@brightwave.co.za <lusanda.mbane@brightwave.co.za> *Web: * www.brightwave.co.za *Address:* 1st Floor, 293 Kent Avenue, Randburg 2194 Shop08, Protea Point Shopping Center, Ndaba Street, Protea North, Soweto -- Disclaimer and Confidentiality Warning - This message is intended for the addressee only. If you are not the intended recipient of this message, you are notified that any distribution, use of or copying of this communication is strictly prohibited. If you have received the communication in error, please notify the sender immediately. The views and opinions expressed in this message are those of the individual sender of this message and do not necessarily represent the views and opinions of Brightwave Technologies Consequently, Brightwave Technologies does not accept responsibility for such views and opinions and this message should not be read as representing the views and opinions of Brightwave Technologies without subsequent written confirmation. Each page attached hereto must also be read in conjunction with this disclaimer.
On Mar 12, 2018, at 11:00 AM, Pierre Delamotte <pierre.delamotte@brightwave.co.za> wrote:
Agreed that the NAS is crappy, but ditching it is not an option for the moment (it is one of my main Capwap controller), so I have to leave with it.
Then complain to the manufacturer, and tell them to fix it.
Knowing that at least the NAS is signalling Freeradius when it is rebooting,
Is it? FreeRADIUS has accounting queries which look for a reboot ("Acct-Status-Type = On"), and close all open sessions for that NAS. So the problem *should* be fixed on the FreeRADIUS side, if the NAS follows *some* of the RADIUS standards.
could I consider the option of updating a radacct record acctuniqueid (I see that the field is defined as Unique Key NOT NULL) targeted by a stop by setting the value to NULL?
Playing games with the schema is a bad idea. It's better to fix the problem.
Should I expect bad side effects?
Yes. The larger questions is why is this happening? Even if the NAS re-uses Acct-Session-Id values, FreeRADIUS will create and use Acct-Unique-Session-Id. Which will solve the problem. So... *why* are these sessions being re-opened? Right now, you're trying random solutions. It would be much better to find the *problem*. Which then leads you to the correct solution. Alan DeKok.
participants (2)
-
Alan DeKok -
Pierre Delamotte