Arran Cudbard-Bell wrote: > * In the default SQL accounting schemas %S is used over the > Event-Timestamp attribute included in the accounting packet. I guess > this is because of the potential drift between NAS, and it makes > correlation easier. Is this the real reason or is it just an omission ?
Many NASes have broken clocks. Many, many, have broken clocks. > * RFC 2869 Specifies the format of Event-Timestamp to be number of > seconds since the Unix Epoch. Yet FR prints it as Event-Timestamp = > "Apr 24 2008 20:06:52 BST". Is this FR's interpretation of the integer > timestamp as a date string or is the NAS sending the timestamp as a string? It's being *printed* as a string. The contents of it in the packets are always 32-bit integers. It may be worth adding some logic to the server to double-check for "bad" Event-Timestamps... > * In accounting detail packets, a timestamp attribute is included. But I > can't figure out how to access it as an attribute when the detail > entries are read back into the server. Any ideas how to ? Hmm... you can't. It may be useful to add it as something like Packet-Original-Timestamp, to distinguish it from Event-Timestamp. That's not hard to do. > It would be > better to use this in accounting queries than %S and there will be a > delay between the packet arriving and the packet being inserted into the > SQL db. Yes. But the server adds Acct-Delay-Time to the accounting packet, with exactly that time difference. But I see what you mean... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
