RadAcct Issue

[Richard J Palmer]

Good Evening (Again)

OK Humble pie time....

I think I found and fixed this issue - and after all I said it was in 
the stored procedure

There was some code to track login state based on the radius session - 
it had some code to be failsafe just in case there was not a session 
(ie we had a duplicate end session call).


Howver while that did not return -1 something within it was triggering 
FreeTDS and therefore FreeRadius to see a -1.


Most odd - I've changed how that works and it seems happy. This was 
necer a comment / issue specifically about FreeRadius - but more 
asking if I'd missed anything - and it seems I had...


> --- Original message ---
> Subject: Re: RadAcct Issue
> From: Richard J Palmer <richard at merula.net>
> To: FreeRadius users mailing list 
> <freeradius-users at lists.freeradius.org>
> Date: Wednesday, 03/11/2021 10:08 PM
>
>
> Good Evening Alan
>
> This is currently a slightly old install - FreeRADIUS Version 3.0.19.
> I have however just upgraded to 3.0.25 and I'm still seeing the same.
> I also upgraded unixODBC/FreeTDS to the latest release too - just in
> case
>
>
> Just chap from an LNS and data to/from a MS SQL Server.
>
>>
>>
>>>
>>>
>>> Running the Query on the MS SQL server I see:
>>>
>>> ---
>>> (1 row affected)
>>>
>>> (1 row affected)
>>>
>>> ---
>>>
>>> So it is correctly updating records - the stored procedure is safe as
>>> long as it returns success.
>>
>>        Well, RADIUS does all kind of asynchronous updates to sessions. 
>>  So
>> there's no guarantee that the session database is the same when you
>> run the query, and when FreeRADIUS runs the query.
>>
>
> This is actually a session that's ended - the SQL table before the
> query shows the  data for this session all correct and ended - In this
> case it's trying time and time again to update the session to finished
> - so radacct (for this session at least) won't be changing - I'm
> wondering if this is a result of the update effectively not affecting
> the data because it's updating the recored to exacly as it is already?
>
>
>>
>>
>>>
>>>
>>> 1) Can you think why FreeRadius is getting -1 as a return.
>>
>>        The TDS / MS-SQL client library is returning that.
> Indeed :)
>>
>>
>>
>>
>>>
>>>
>>> 2) Given the stored procedure will return an error IF it can't update
>>> the data - is there anyway for us to tell FreeRadius to accept and
>>> process OK as long as the Query works.
>>
>>        Except that the SQL library says the query *didn't* work.
> Agree - badly worded - I meant the Stored procedure is written  so
> it's virtually impossible for the data we need not to be saved - and I
> know there can always be edge cases...
>
>
> As long as we get
>
> (142) sql1: SQL query returned: success
>
> It's processed the update OK - I'm happy to share the Stored procedure
> if it helps - I'd just prefer it not to be totally in the public.
> I know in some cases this may not be acceptable - but in this
> particular use case at the end of a session - worse case the process
> that cllses zombie sessions will close the session in the background a
> bit later on.
>
> Richard
>
>
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html