Hello Jerome -
I think the correct answer would be to have different processing for "Timestamp" and "Event-Timestamp", not to override what is currently done by Radiator with "Timestamp", given that they are different ideas of what "time" is.
In any case, if "Event-Timestamp" is present in a request, then it will not interfere with Radiator's own "Timestamp". And it is available as the special character %{Event-Timestamp}, exactly like %{Timestamp} is, so you needn't write a hook anyway (as mentioned in my previous mail).
regards
Hugh
On Thursday, October 24, 2002, at 09:47 PM, Jerome Fleury wrote:
--On Thursday, October 24, 2002 04:11:44 PM +1000 Hugh Irvine <[EMAIL PROTECTED]> wrote:NB: I am travelling this week, so there may be delays in our correspondence.
I understand your point of view about that patch. But keep in mind that Event-Timestamp is a standard Radius Attribute defined in RFC2869 (Radius Extensions), that should be implemented by more and more devices as time goes on.
Hi Mike -
I don't agree with changing Radiator's Timestamp.
If there is an Event-Timestamp in a request and someone wants to use it,
it is simple enough to use special characters (%{Event-Timestamp}),
and/or write a hook to make whatever changes are wanted/needed on a local
basis.
This attribute has been added so that the server should not calculate timestamps but let network devices do this job.
Therefore Radiator should allow the use of this attribute (if it exists) in a more friendly way than having to write a hook.
--
Jerome Fleury
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
