On Oct 3, 2016, at 6:13 AM, Anirudh Malhotra <8zero2ops@gmail.com> wrote:
I have a 2 tier question First would mention the simultaneous verify query for reference simul_verify_query = "\ SELECT \ radacctid, acctsessionid, username, nasipaddress, nasportid, framedipaddress, \ callingstationid, framedprotocol \ FROM ${acct_table1} \ WHERE username = '%{SQL-User-Name}' \ AND acctstoptime IS NULL" One: I see many posts for deletion of stale sessions not working, One particular post which pretty close to solving the non working problem was: http://lists.freeradius.org/pipermail/freeradius-users/2015-November/080816....
OK...
The posts conclusion was that fake accounting packet doesnt have the same acct-session-id as that of the stale session that is why it is not able to close it. As acct-unique-session-id(md5 of some attributes including acct-session-id NAS-Identifier etc) comes out to be different.
But what i found from a little analysis was that actually the acct-session-id is not the problem but the "NAS-Identifier" is. The NAS-Identifier was being sent in a normal accounting packet(atlease in my case maybe not in somebody else's) but it was not being sent in the "fake accountng query" as it is not present in the radacct table it is not fetched from the table as can be seen in the query above.
The solution then is to fetch the Acct-Unique-Session-Id, and to use that.
Two: I noticed some anomaly in simultaneous verify query in sql and when the attributes are selected to actually delete stale sessions, I am running 3.0.11.
which selects radacctid, acctsessionid, username, nasipaddress, nasportid, framedipaddress, callingstationid, framedprotocol. That is 8 attributes from the radacct table. And somehow my stale sessions were all getting acctsessiontime as 0
OK...
The code above makes use of 9 attributes last one being(row[8]) acctsessiontime which was not getting fetched in the query. For that reason it always picks the value as 0 for acctsessiontime which is not ideal(a guess).
I'll push a fix. You can also calculate the "stop time" as the time when the ZAP packet was sent. i.e. if there's no time in the packet, use Event-Timestamp, or "now". Alan DeKok.