(RADIATOR) Timestamp Attribute Handling...

[Rickard Ekeroth]

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.