Checkrad problem with Acct-Unique-Session-Id

[SC SCx]

Hi,

Since I cant control the session id beween Access-Requests:

* user connects *
1) Access-Request ( acct-session-id: 7427542-L_pppoe1-1 )
2) Accounting-Request

* ... nas gets killed at this point and reboots ... *

* user connects again *
3) Access-Request (acct-session-id: 7427566-L_pppoe1-1)
4) Accounting-Request

I will most likely resort to a combination of a cronjob (to set acctstop
time to a non null value) for entries that had not been updated for some time
interval + checkrad.

Cronjob will remove those stale entries created by the "fake accounting stop"
packets. While checkrad will prevent being locked out in presence of such stale
entry until cronjob cleans it up.

Not as pretty as checkrad taking care of both, but I think it will be the
easiest compromise.

Thank you !!!

2015-11-14 15:15 GMT+01:00 Alan DeKok <aland at deployingradius.com>:

> On Nov 14, 2015, at 8:30 AM, SC SCx <kredaxx at gmail.com> wrote:
> > The access request received has a different Acct-Session-Id:
> > 7427566-L_pppoe1-1 (the previous one was: 7427542-L_pppoe1-1)
>
>   Which is allowed.  BUT if you need to delete the old session, you need
> to use the old Acct-Session-Id.
>
> > Since this Access-Request has a different Acct-Session-Id, the hash value
> > of Acct-Unique-Session-Id is different.
>
>   Yes.  Use the old Acct-Session-Id for the "delete old session".  Or,
> don't use an Acct-Session-Id.  Just key off of the old session information.
>
> > An update query is called to remove the stale session, but because of the
> > different Acct-Unique-Session-Id it doesn't match the previous session
> > entry.
> >
> >  UPDATE radacct SET acctstoptime = FROM_UNIXTIME(1447427566),
> > acctsessiontime    = 192, acctinputoctets  = '0' << 32 | '0',
> > acctoutputoctets = '0' << 32 | '0', acctterminatecause = '',
> > connectinfo_stop = '' WHERE AcctUniqueId =
> > '9785b846930595ba6d83f5955a13fa1d'
>
>   Which uses the old Acct-Session-Id...
>
> > Then a queued? (Says 'trying next query...') query is called which
> inserts
> > a new session entry to radacct table:
>
>   It can't do an update, so it fails over to insert.
>
>   Which it shouldn't do for the "delete old session" functionality.  If
> the old session doesn't exist, it shouldn't do anything.
>
>   The underlying problem here is that the server assumes Access-Request
> packets don't contain Acct-Session-Id.  On top of that, the "session"
> functionality has code to create a fake Accounting-Request "stop" packet,
> and you can't manually edit the contents of that packet.  And, it runs the
> accounting packet through the normal accounting section... instead of a
> specific "stop session" section.
>
>   What you *can* do is check for this fake packet in the accounting
> section.
>
> accounting {
>         if (outer.request:User-Name) {
>                 # it's a fake accounting packet
>                 # do special things to delete old sessions
>
>                 return
>         }
>
>         ... existing accounting stuff...
>
> }
>
>   Arran and I are re-doing the server architecture for 3.1.  That should
> make all of this much easier and more consistent.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html