(RADIATOR) hook program's variable lifetime

Tue Apr 11 08:54:21 CDT 2006

Hello Kaiser-

You have to remember that the hook is not a complete perl program. It is a
subroutine that is run as part of the main Radiator program. So each time
the hook is ran it is not a new process. If you assign a value to a variable
that value will remain until it is changed.

The statement 

$a=$p->get_attr('Acct-Delay-Time') if $p->get_attr('Acct-Delay-Time') gt 0;

will only change the value of $a if the attribute 'Acct-Delay-Time' is
greater than zero. So if you call the hook once and assign a value to $a and
the next time the hook is ran $a will be the same value unless you
initialize the variable using some value or declare it as a local variable
so it will not exist outside of the subroutine.

This is all part of good Perl coding and is the reason for declaring
variables with 'my' in the beginning of your subroutine. Using 'my $a=0' at
the beginning of the hook will solve a lot of problems.

Perl is very forgiving and will let you use an unitialized global variable
even if it will do things you do not expect. There is some good
documentation available on the internet that explains how Perl uses global,
local, and my variables. Very similar things happen with mod_perl under
Apache and some of the mod_perl tutorials do a very good job of explaining
how to treat variables.

Frank Danielson
Infrastructure Architect

ClearSky Mobile Media
56 E. Pine St.
Orlando, FL 32801
USA

fdanielson at csky.com

-----Original Message-----
From: kaiser [mailto:kaiser at gentrice.net]
Sent: Tuesday, April 11, 2006 6:08 AM
To: Hugh Irvine
Cc: radiator at open.com.au
Subject: Re: (RADIATOR) hook program's variable lifetime

Hi,

Thanks for your reply.

Yes, as you said Acc-Delay-Time is for re-transmit issue.
It looks like our radius client use this attribute for other purpose.

Our radius client will generate 3 acccounting packet for a service:
Accounting Start, accounting alive, and stop.
So, the hook program will be run 3 times becuase there are 3 accounting
packet ...

The Acc-Delay-Time will be put in the packet of accounting alive.
Our perl program will put this value in a variable $a when accounting alive
arrived.
for example $a will be assigned with a value , 10.

but we feel strange that we still can access this variable's value when hook
perl program called for stop accounting packet coming...
we still can find 10 is the value of $a....
If the variable's life time is available during execution time, we should
not get 10 from $a when next time perl excuted.

Hope you could understand my English. Thanks.

best regard
kaiser

----- Original Message ----- 
From: "Hugh Irvine" <hugh at open.com.au>
To: "kaiser" <kaiser at gentrice.net>
Cc: <radiator at open.com.au>
Sent: Tuesday, April 11, 2006 3:33 PM
Subject: Re: (RADIATOR) hook program's variable lifetime

>
> Hello Kaiser -
>
> I'm not quite sure I understand what you are trying to do.
>
> The Acct-Session-Time is only available in the accounting stop packet
> as its value is the length of time the session was up.
>
> The Acct-Delay-Time is only ever non-zero when an accounting request
> has been re-transmitted due to a radius timeout, but it has no
> bearing on the Acct-Session-Time that is contained in the request.
>
> You should also note that the Radiator "Timestamp" attribute that is
> added to the radius accounting requests is automatically corrected
> for any non-zero Acct-Delay-Time that is present in the request.
>
> What exactly are you trying to do?
>
> regards
>
> Hugh
>
>
> On 11 Apr 2006, at 11:27, kaiser wrote:
>
> > Hi,
> >
> > Thanks for your reply....
> >> If you mean a variable in a hook - such variables are only
> >> instantiated for the duration of the execution of the hook.
> >
> > I think radiator should work this way...
> >
> > But I used to do a test :
> >
> > In radius.cfg:
> > <Handler NAS-Port="1000">
> >         PreProcessingHook file:"/etc/radiator/cost2.pl"
> >
> >
> > In hook perl program cost.pl:
> >                 $a=$p->get_attr('Acct-Delay-Time') if
> > $p->get_attr('Acct-Delay-Time') gt 0;
> >                 $b=$p->get_attr('Acct-Session-Time') if
> > $p->get_attr('Acct-Session-Time') gt 0;
> >
> >
> > We find Acc-Delay-time only be sent from our radius client when server
> > service is connected.
> >
> > When accounting stop packet arrived, we can get Acct-Session-Time
> > But we feel strange that in our perl code ( I believe it is not a
> > correct
> > way), we can keep Acct-Delay-Time's value in $a when stop
> > accounting arrived
> > .
> > We can't get Acct-Delay-Time in stop accounting, we only can see
> > Acct-Delay-Time in pervious accounting packet.
> >
> > Can you confirm the method we write the code here ?
> >
> >
> > best regard
> > kaiser
> >
> >
> > ----- Original Message -----
> > From: "Hugh Irvine" <hugh at open.com.au>
> > To: "kaiser" <kaiser at gentrice.net>
> > Cc: <radiator at open.com.au>
> > Sent: Tuesday, April 11, 2006 8:10 AM
> > Subject: Re: (RADIATOR) hook program's variable lifetime
> >
> >
> >>
> >> Hello Kaiser -
> >>
> >> I don't understand your question, sorry.
> >>
> >> The Acct-Session-Id is generated by the NAS equipment according to
> >> whatever algorithm it has in its internal code.
> >>
> >> I would expect that the same Acct-Session-Id could be seen multiple
> >> times (ie. it will not be unique).
> >>
> >> If you mean a variable in a hook - such variables are only
> >> instantiated for the duration of the execution of the hook.
> >>
> >> hope that helps
> >>
> >> regards
> >>
> >> Hugh
> >>
> >>
> >> On 10 Apr 2006, at 21:55, kaiser wrote:
> >>
> >>> Hi,
> >>>
> >>> We use hook prel program for external job, it works fine...
> >>> But I personal feel something unclear:
> >>> Perl program seems could keeps variable value in differnt
> >>> accounting request with the same Acct-Session-Id
> >>> Is it real ?
> >>>
> >>> best regard
> >>> kaiser
> >>>
> >>>
> >>>
> >>
> >>
> >> 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.
>
>
> 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.

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