Ok. RFC says exactly that "The Value field is four octets encoding an unsigned integer with the number of seconds since January 1, 1970 00:00 UTC."
I did not think radiusd rewrites unix timestamp into date.
Just because previous radius i was using used to put the timestamp into accounting as an integer.
Moreover i did not notice this helpful trick in variables.txt:
" %S request timestamp in SQL format"
Does it mean that %S takes the timestamp from the Event-Timestamp field of the accounting packet?
-- SY, Alexander
Alan DeKok wrote:
Alexander <[EMAIL PROTECTED]> wrote:
This RFC says the attribute to be unsigned integer. Why is it "date" in dictionary.rfc2869?
Because it's a date. See RFC 2866 for a definition of the "time" type. It's the same as "date", and is stored as a 32-bit integer.
If we name the file with rfc number, then why didn't we follow it ? It's not difficult to change the attribute every time i upgrade, but ...
Why the heck are you changing the attribute? It's a date. It gets printed and parsed like a date. What goes into the RADIUS packet is a 32-bit integer, because that's how dates are represented in the protocol.
Do you really want to see and type in all dates in your system as 32-bit integers? That's how they're represented internally in Unix.
I'm at a complete loss for why you would want to change the type of the attribute. What do you hope to gain by it?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html