(RADIATOR) Timestamp Attribute Handling...

[Hugh Irvine]

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.