Create New Session Based On Accounting Update

Alan DeKok aland at deployingradius.com
Sun Feb 23 15:19:07 CET 2020


On Feb 23, 2020, at 8:59 AM, One Zero Art <onezeroartapps at gmail.com> wrote:
> In debug mode I can see that freeradius updating radacct table row but not
> inserting new session.

  If there's no existing session, it should INSERT a new one.

> I am not sure if I missed any config in SQL or somewhere else.
> 
> *This is my issue. *
> 
> Currently, the user offline in freeradius ==* acctstoptime is not null*,
> but the user online in the router so the router sending data to the
> server continuously.

  So why is there anything in acctstoptime?  FreeRADIUS doesn't invent accounting data. It simply stores what the NAS sends it.

  The problem is very likely to be that the NAS is sending the wrong information to FreeRADIUS.  OR the NAS is sending the *same* data for two different sessions.

> In SQL queries.conf I can see there is the SQL query to insert a new
> session when interim update received by server but for me it's not
> happening.

  Run the server in debug mode to see why...

> *SQL queries.conf file *

  I don't need to see the configuration files.  I *do* already have access to them,

> *My debug code*
> (0) Received Accounting-Request Id 12 from 192.168.43.120:45516 to
> 192.168.43.100:1813 length 255
> (0)   Service-Type = Framed-User
> (0)   Framed-Protocol = PPP
> (0)   NAS-Port = 15728640
> (0)   NAS-Port-Type = Ethernet
> (0)   User-Name = "@114"
> (0)   Calling-Station-Id = "08:00:27:B9:4B:F2"
> (0)   Called-Station-Id = "pppoe"
> (0)   NAS-Port-Id = "lan"
> ...
> (0)   Acct-Session-Id = "81400000"

  Those are all attributes which identify a particular user session.

  Is the NAS sending the *same* attributes for *different* user sessions?

  Again, read the debug output to see.
...
> (0) sql: EXPAN*D UPDATE radacct SET acctupdatetime * =
> (@acctupdatetime_old:=acctupdatetime), acctupdatetime  =
> FROM_UNIXTIME(%{integer:Event-Timestamp}), acctiestamp} -
> UNIX_TIMESTAMP(@acctupdatetime_old), framedipaddress =
> '%{Framed-IP-Address}', acctsessiontime = %{%{Acct-Session-Time}:-NULL},
> acctinputoctets = '% 32 | '%{%{Acct-Input-Octets}:-0}', acctoutputoctets =
> '%{%{Acct-Output-Gigawords}:-0}' << 32 | '%{%{Acct-Output-Octets}:-0}'
> WHERE AcctUniqueId = '%{Acct-Uni
> (0) sql:    --> *UPDATE radacct SET acctupdatetime*  =
> (@acctupdatetime_old:=acctupdatetime), acctupdatetime  =
> FROM_UNIXTIME(1582482257), acctinterval    = 158datetime_old),
> framedipaddress = '192.168.10.254', acctsessiontime = 150, acctinputoctets
> = '0' << 32 | '7616', acctoutputoctets = '0' << 32 | '248' WHERE
> Acc0d66dd53f5e5b'
> (0) sql: Executing query: UPDATE radacct SET acctupdatetime  =
> (@acctupdatetime_old:=acctupdatetime), acctupdatetime  =
> FROM_UNIXTIME(1582482257), acctintervaMP(@acctupdatetime_old),
> framedipaddress = '192.168.10.254', acctsessiontime = 150, acctinputoctets
> = '0' << 32 | '7616', acctoutputoctets = '0' << 32 |
> '248'e0819c39a40d66dd53f5e5b'
> rlm_sql_mysql: Rows matched: 1  Changed: 1  Warnings: 0
> (0) sql: SQL query returned: success

  That is pretty clear.

  There is an existing session for the user in SQL.  So, the server updates it.  This is what it's supposed to do.

  If the row in the DB is for a *different* user session, then how does FreeRADIUS know that?

  i.e. you might think it's for a different session, but why?  What *RADIUS* information makes it a different session?

  Alan DeKok.




More information about the Freeradius-Users mailing list