(RADIATOR) Session Handling...

Fri Apr 22 04:48:03 CDT 2005

Hello Hugh!

Thank you for your answer!

This is exactly what I am doing. It is only that when Radiator is going to
delete a session from the session list because it is not online anymore it
is NOT using values from the current packet but rather from what is
recovered from the 'CountQuery'. That is why I have the problem with my
'%{Class}' attribute because that one is from the current packet rather than
from the 'CountQuery'.

Do you see my point?

-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: 22 April 2005 12:13
To: Rickard Ekeroth; Mike McCauley
Cc: Ranko Zivojnovic; Andreas Michaelou; 'radiator at open.com.au' Mailinglist;
George Georgiou
Subject: Re: (RADIATOR) Session Handling...

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.