(RADIATOR) Timestamp Attribute Handling...

[Hugh Irvine]

Hello Richard -

I think the StripFromRequest will remove all instances of an attribute, 
but you should test it to make sure.

BTW - you can also use "AllowInRequest" to explicitly list what 
attributes you will forward.

regards

Hugh


On 24 Jan 2005, at 19:57, Rickard Ekeroth wrote:

>
> Hello!
>
> Thank you for the clarification. I obviously did not do my 'RTFM' 
> properly.
> However I think that perhaps it is not entirely clear from the manual 
> that
> the 'Timestamp' attribute will actually stay in the request as it is 
> being
> sent on (if proxying). I guess it is logical what is happening if you 
> do a
> bit of thinking about it and know how things work, but anyway...
>
> I think that I will go with the stripping approach as it will probably 
> make
> sure that the log confusions will go away even if the clocks of the 
> machines
> are a bit out of sync. Will the strip statement strip all the 
> 'Timestamp'
> attributes if there are more than one in the request or just the one 
> added
> by that particular Radiator?
>
>
> -----Original Message-----
> From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]On
> Behalf Of Hugh Irvine
> Sent: 22 January 2005 00:44
> To: rickard at spidernet.net
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) Timestamp Attribute Handling...
>
>
>
> Hello Richard -
>
> Thanks for your mail, and yes this has come up before on the mailing
> list but I don't mind discussing it again.
>
> The Timestamp attribute is described in section 6.29.14 of the Radiator
> 3.11 reference manual ("doc/ref.html"):
>
> .....
>
>   The attribute Timestamp is always available for insertion, and is set
> to the time the packet was received, adjusted by Acct-Delay-Time (if
> present), as an integer number of seconds since Midnight Jan 1 1970
> UTC. The Timestamp atttribute is added by Radiator to all received
> Accounting requests, and is set to the current time according to the
> host on which the Radiator is running.
>
> .....
>
> The simplest way to deal with the problem you describe is to strip the
> Timestamp attribute from the proxied requests if required:
>
> 	<AuthBy RADIUS>
> 		.....
> 		StripFromRequest Timestamp
> 		.....
> 	</AuthBy>
>
> regards
>
> Hugh
>
>
> On 21 Jan 2005, at 22:28, Rickard Ekeroth wrote:
>
>>
>> Hello!
>>
>> I have some thoughts about how the timestamp attribute, accounting and
>> proxying.
>>
>> I have noticed that Radiator adds a 'Timestamp' (103) attribute to any
>> incoming accounting request (it does not seem to happen for access
>> requests). As I understand this 'Timestamp' attribute is the current
>> time
>> adjusted for any 'Acct-Delay-Time', if present. This is all ok.
>>
>> Now what I find a bit 'fishy' is that this 'Timestamp' attribute
>> actually
>> stays in the request as it is being sent on when you are proxying
>> RADIUS
>> requests. This has the effect that for every Radiator proxy hop there
>> is a
>> new Timestamp attribute added (since the code in 'Handler.pm' does not
>> check
>> if it is already there). I just wanted to know if this is a 'bug' or a
>> 'feature' since it caused me some headache before I understood what 
>> was
>> going on. If it is a 'feature' perhaps it should be mentioned in the
>> documentation somewhere.
>>
>> The problem was that I had two machines. One proxy Radiator and the
>> final
>> destination Radiator. The clocks on these two machines were five
>> minutes out
>> of sync (which they of course should not be in the first place).
>> Anyway, I
>> was getting funny logs having the access requests happening after the
>> session starts (acct start). I guess this is because the timestamp
>> attribute
>> is only added to accounting requests and not to access requests
>> (according
>> to the source in 'Handler.pm'), so I was only receiving out-of-sync
>> timestamps for the accounting requests from the proxy radiator and not
>> for
>> the access requests.
>>
>> Perhaps this has been discussed before on this list and I beg your
>> pardon if
>> I am causing some repetition on the subject.
>>
>> 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.
>
> --
> 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.