(RADIATOR) Session Handling...

[Hugh Irvine]

Hello Richard -

You can redefine the queries in the SessionDatabase SQL clause to use 
any attributes that are available. You are not limited to only the %0, 
%1, etc. - you can use any attributes by specifying them thus: 
%{Any-Attribute}. See the examples in section 6.8 in the Radiator 3.12 
reference manual ("doc/ref.html").

The reason for the current behaviour regarding SNMP errors is to fail 
gracefully - ie. not to deny access in "degraded" operation. The theory 
being that it is better to err towards providing service rather than 
denying service. I will forward your mail to Mike however so he can 
think about your points.

regards

Hugh


On 22 Apr 2005, at 18:40, Rickard Ekeroth wrote:

>
> 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.
>
>

NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive 
(www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
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.