(RADIATOR) hook program's variable lifetime

Tue Apr 11 05:07:48 CDT 2006

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.