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 <[email protected]
<mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
http://www.open.com.au/mailman/listinfo/radiator
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
