Simultaneous sessions and deleting stale sessions

[Alan DeKok]

On Oct 3, 2016, at 6:13 AM, Anirudh Malhotra <8zero2ops at 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.html

  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.