(RADIATOR) Timestamp Attribute Handling...

[Rickard Ekeroth]

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.