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@merula.net> To: FreeRadius users mailing list <freeradius-users@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