(RADIATOR) Session Handling...

[Rickard Ekeroth]

Hello!

I am having some thoughts about session handling in Radiator.

I am using not only 'NASIPAddress', 'NASPort' and 'AcctSessionId' to
identify a session but also 'NASPortId' and 'Class'.

The reason for this is that we have some NASes that do not even report a
'NASPort' (nor an initial 'AcctSessionId') but they do return the 'Class'
attribute so we use that.

I have just started to look into using SNMP to query some NASes about the
session count. I have found two problems that I want to tell you about.

The first one is the fact that when the 'DeleteQuery' is called because a
session is found not to be online only 'NASIPAddress', 'NASPort' and
'AcctSessionId' have replacement characters. This creates me some problems
since I am supplying 'Class' and 'NASPortId' from the current package
aswell. On access request I am adding the 'Class' attribute to the current
package in the 'AuthSelect' in my 'AuthBy SQL' clause, which happenes before
the sessions are counted and any potential delete happens because of any NAS
SNMP query. That 'Class' attribute is then used in preference over
'NASIPAddress' and 'NASPort' in my session delete stored procedure since I
know that all my 'Class' attributes are globally unique (GUID). I have been
able to fix it by supplying the 'AcctStatusType' attribute to the
'DeleteQuery' aswell and by examining if it is 'Stop' or empty I can decide
if I should use the 'Class' attribute or not.

Would it be possible to allow for the 'Class' and 'NASPortId' attribute
columns to be added to the output of the 'CountQuery' and have them consumed
and replaced with e.g. '%4' and '%5' on the 'DeleteQuery'? This would help
me to provide a cleaner solution.

The other is about the behaviour of Radiator when there is an 'snmpget'
error. If there is an error in getting session info from a NAS the immediate
result is to assume that the session in question is NOT online. However in
the subsequent attempts (while there is a backoff period of 60 seconds) the
assumption is the reverse, i.e. that the session is still on the NAS. In my
mind it is not correct to assume that the session is gone just because I can
not contact the NAS. The answer to that question is actually undefined in
that case. I think that the behaviour is correct during the backoff period
but not with the initial error. I would prefer not to have my session table
modified because of an undefined answer. Is there a way that I can control
this behaviour with some kind of configuration?

Thank you for your attention and have a nice day!


Regards,

Rickard Ekeroth @ SpiderNet
Software Developer / Analyst
rickard at spidernet.net
+35722844870

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.