[RADIATOR] Delayed Stop Record and Active Sessions

[Michael]

Hi Rohan,

I think you pretty much should be deleting sessions using the session id 
included in the delete criteria, for accuracy.  But, NOT using the 
session id in your count query.

The 'state limit' function i think you are referring to is tough to do.  
I assume you mean user session limits.  I don't think you can actually 
implement session limits accurately.   It's just not possible to do it 
"accurately".  yes, the options are there and the idea exists, but i 
don't think it can ever be as accurate as you would expect it to be.  
Even if you solve your issues described here, there's always a 
possibility active sessions fail/drop/die and your device still holds 
onto that session for a given time until it realize that the session 
truly is lost, then sends the Stop packet. Maybe your problem is not 
delayed stop packets, but sessions that just have not stopped yet 
because the device still thinks the session is active.

So ya, when user logs back in, if you for example have session limits of 
1, you are now rejecting your user. My personal experience is you need 
to have a very solid infrastructure (like fiber) to your customers and a 
low 'keep alive' time in order to have strict user session limits.  But, 
for an infrastructure like cable/dsl where sync's are lost, things drop, 
and other problems, you may want to think about using n + 1.  Meaning, 
your desired session limit, plus 1.  This allows your customer to always 
log back in if their session drops but they're old session still shows 
active.  Yes, they can now have 1 more session than you want to allow.  
It's a trade off.  If you want to be strict, you have to expect your 
users to be rejected due to dead sessions.


On 21/02/14 04:21 PM, rohan.henry @cwjamaica.com wrote:
> Thanks for the feedback Heikki.
>
> I am thinking that the suggestion would solve the problem but defeats 
> the state limit function. It means that a connection would now become 
> unique based on Acct-Session-Id which changes for every connection and 
> would grant access to the same user multiple times since the new 
> Acct-Session-Id will not allow a database match.
>
> Rohan
>
>
>
> On Wed, Feb 19, 2014 at 3:40 PM, Heikki Vatiainen <hvn at open.com.au 
> <mailto:hvn at open.com.au>> wrote:
>
>     On 02/19/2014 09:22 PM, rohan.henry @cwjamaica.com
>     <http://cwjamaica.com> wrote:
>
>     > How can fix an issue where the DeleteQuery statement in my
>     Sessions DB
>     > config deletes the row for a new active session because of a delayed
>     > Stop record?
>
>     A quick idea: Do you think the DeleteQuery could be changed to include
>     Acct-Session-Id in the query. That is, the NAS-Port, etc, and
>     Acct-Session-Id must match the existing entry.
>
>     If the session has been replaced, the delete will not match any rows
>     because the new entry on the row it would otherwise match has a
>     different session id that belongs to the new session.
>
>     Please let us know how this works.
>     Thanks,
>     Heikki
>
>
>     > Scenario:
>     >
>     > 1. A session is up (and row entered in the database for active
>     session)
>     > 2. The session is dropped because of a premature disconnection (eg.
>     > modem line cable unplugged) but Stop record is delayed.
>     > 3. New session is created after modem line cable is restored
>     (and after
>     > DeleteQuery statement removes database row for previous session)
>     > 4. The delayed Stop record finally comes in - the DeleteQuery
>     statement
>     > now removes the row for the active session (An unwanted behavior).
>     >
>     > How do I compensate for the delayed Stop record that is causing
>     active
>     > session database records to be deleted?
>
>
>     --
>     Heikki Vatiainen <hvn at open.com.au <mailto:hvn at open.com.au>>
>
>     Radiator: the most portable, flexible and configurable RADIUS server
>     anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>     Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP,
>     TLS,
>     TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>     DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
>     NetWare etc.
>     _______________________________________________
>     radiator mailing list
>     radiator at open.com.au <mailto:radiator at open.com.au>
>     http://www.open.com.au/mailman/listinfo/radiator
>
>
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20140223/aa93c6b8/attachment.html