SQL session start

Alan DeKok aland at deployingradius.com
Fri Sep 13 18:36:45 CEST 2019


On Sep 13, 2019, at 12:25 PM, Marcin <m.marszal at wp.pl> wrote:
> 
>> So what's in SQL?  Does the AcctUniqueId match?
> 
> Yes it does and no, it doesn’t. Most often, AcctUniqueId is inserted but sometimes not.

  So... read the debug output to see what's different between the two cases.  The debug output shows you which attributes are being used to calculate AcctUniqueId.

  If the input attributes are different, then the output hash is different.  Maybe your NAS sends *different information* in the Access-Request and Accounting-Request packet.  Again, go read the debug output to see the differences.

  Then if you can't fix the NAS to be consistent, edit the Acct-Unique-Session-Id calculation.  Make it use the attributes which exist in both packets.

> And if it’s in table, sometimes not all columns in radacct table are updated. Affected are:
> acctupdatetime   acctstoptime   acctinterval	acctsessiontime   connectinfo_stop   acctinputoctets	acctoutputoctets  framedipaddress

  Again, if you READ the debug output, it will SHOW YOU which attributes are in the packet.  This isn't rocket science.  The server doesn't magically invent things to put into the DB.

  FreeRADIUS can log ONLY what the NAS sends.  So if the NAS sends different attributes in different packets, then blame the NAS.  Don't look at SQL and go "gosh, I don't know what's going on".

>> What was inserted into SQL when the Access-Accept was sent?
> 
> Inserted values are either NULL or „0” (in acctsessiontime, acctinputoctets and acctoutputoctets) - which reflects initial - postauth entry. So, I guess it’s right.

  That is entirely missing my point.

> In general, it seems like table is updated inconsistently.

  Blame the NAS.

  This isn't magic.  FreeRADIUS doesn't magically skip certain fields at random. 

> Since there are no any accounting errors  when sql_session_start is disabled, I think it's must be related to that particular feature or maybe to mysql database itself?

  Think about it.  Is the database really magically causing data to disappear?  Or is FreeRADIUS randomly deciding to *not* insert certain fields?

  Or maybe, if you READ THE DEBUG OUTPUT, you will see that the NAS sends different information in different packets.  And when information is "missing" from SQL, it's because that information is ALSO missing from the accounting packet.

  The information you need to understand this problem is in the debug output.  All you need to do is read it.  Looking at the SQL database means that you're 3 steps removed from the actual problem.

  Alan DeKok.




More information about the Freeradius-Users mailing list