Re: Event-Timestamp attribute
Alan DeKok wrote: Alexander Serkin [EMAIL PROTECTED] wrote: No. It takes the time that the packet was received. The Event-Timestamp attribute MAY be a lie. oops. When and why? Have not seen a lie from cisco NASes yet. Set the time wrong on the Cisco box, then look at Event-Timestamp. Set time wrong on radius host, then look at %S. Nonsense. ... Stop complaining that the server is broken, fix your configuration, and go away. One more nonsense. Nobody said the server is broken. I just needed some hints. You've directed me in a proper way. Thank you. Have some beer and calm down. -- als - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Event-Timestamp attribute
Alexander Serkin wrote:
Edit oraclesql.conf to use the query you want. That's why the
queries are configurable.
Shure i will. I've seen them occasionally :-)
The question was to guys who may did the trick already. Because in Oracle
You can parse the string May 18 2005 12:08:18 +0400 easily, but i've
no idea what to do with timezone specified as MSD or something else.
And finally i can modify the timezone presentation by Solaris zone info compiler
so that it would be +0400, but radiusd modifies it into =2B0400, and that
confuses oracle completely:
radius_xlat: 'INSERT into radacct (RadAcctId, AcctSessionId, CallingStationId,
FramedIPAddress, CDMACorrelationId, CDMAHAAgent, UserName, CDMAPCFIPAddress,
CDMABSMSCAddr, CDMAUserId, CDMAIPTech, CDMACompTunInd, CDMABadFrameCount,
CDMAReceivedHDLCOctets, CDMAIPQoS, CDMAAirPriority, CDMARPSessionID,
AcctAuthentic, NASPortType, NASPort, ServiceType, NASIPAddress, NASIdentifier,
AcctUniqueId, Realm, TunnelServerEndpoint, TunnelClientEndpoint,
TunnelAssignmentId, TunnelType, AcctTunnelConnection, TunnelClientAuthId,
TunnelServerAuthId, AcctStartTime, FramedProtocol, AcctStartDelay) values ('',
'1117', '25009700440', '212.119.123.233', '0003A62F', '0.0.0.0',
'mobile', '212.119.99.40', '0001', '0', '1', '0', '0', '1140', '0',
'13', '1', 'RADIUS', 'Virtual', '58503', 'Framed-User', '212.119.97.85',
'pdsn1.cell.ru', '0995358346e1d81e', 'NULL', '', '', '', '', '', '', '',
TO_TIMESTAMP_TZ('Oct 7 2004 12:50:00 =2B0400','Mon dd hh24:mi:ss tzhtzm'),
'', '')'
rlm_sql (sqlacct): Reserving sql socket id: 4
rlm_sql_oracle: execute query failed in sql_query: ORA-01858: a non-numeric
character was found where a numeric was expected
rlm_sql (sqlacct): Attempting to connect rlm_sql_oracle #4
rlm_sql (sqlacct): Connected new DB handle, #4
rlm_sql_oracle: execute query failed in sql_query: ORA-01858: a non-numeric
character was found where a numeric was expected
rlm_sql (sqlacct): failed after re-connect
Alan DeKok.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
--
Sincerely Yours,
Alexander
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Event-Timestamp attribute
Alexander Serkin [EMAIL PROTECTED] wrote: And finally i can modify the timezone presentation by Solaris zone info compiler so that it would be +0400, but radiusd modifies it into =2B0400, and that confuses oracle completely: Look for safe in sql.conf. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Event-Timestamp attribute
Alexander Serkin [EMAIL PROTECTED] wrote: No. It takes the time that the packet was received. The Event-Timestamp attribute MAY be a lie. oops. When and why? Have not seen a lie from cisco NASes yet. Set the time wrong on the Cisco box, then look at Event-Timestamp. It happens. Exactly. You can't trust the NAS. It's a big surprise for me. Get used to it. Just a small example: when subscriber requests packet data usage details we provide a list of his sessions with start-stop times and an amount of bytes in/out. What do you think he would say seing that he has downloaded 300Mbytes in one second while the maximum speed of his mobile terminal is up to 153kbit/s? I have no clue how you arrived at that conclusion. You're suddenly talking about downloads instead of timestamps, and accusing me of being an idiot for getting confused about the subject. You're rude. And annoying. Another issue - police investigations. When department K requests who was online on 25 Dec 2001 00:00:00 whith the ip address 1.2.3.4 - how can we find this session if the data was pushed into database with wrong timing? Stop being ridiculous. The server gives you the ability to store Event-Timestamp in SQL, or %S (server timestamp) in SQL. So you can store what you want, where you want, in the format you want. Stop complaining that the server is broken, fix your configuration, and go away. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Event-Timestamp attribute
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
Re: Event-Timestamp attribute
Alexander Serkin wrote: 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? Hm. That's not a trick. And not good at all. %S takes time at which the request comes to radius. I've pushed a pack of accounting records to the radius with radrelay. When using %S i have a session as this one: id: D4776040004F9475 start - 18-MAY-05 12.25.15, stop - 18-MAY-05 12.25.15 and actual values are: id: D4776040004F9475 start: 18/05/2005 12:03:46, stop: 18/05/2005 12:07:34 does not seem like a valid relay. Now who can give me a hint of pushing Event-Timestamp like May 18 2005 12:08:18 MSD into oracle TIMESTAMP WITH TIME ZONE field? -- Alexander - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Event-Timestamp attribute
Alexander Serkin [EMAIL PROTECTED] wrote: 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. Which I, for one, have a hard time understanding. Does it mean that %S takes the timestamp from the Event-Timestamp field of the accounting packet? No. It takes the time that the packet was received. The Event-Timestamp attribute MAY be a lie. Hm. That's not a trick. And not good at all. %S takes time at which the request comes to radius. Exactly. You can't trust the NAS. I've pushed a pack of accounting records to the radius with radrelay. When using %S i have a session as this one: id: D4776040004F9475 start - 18-MAY-05 12.25.15, stop - 18-MAY-05 12.25.15 and actual values are: id: D4776040004F9475 start: 18/05/2005 12:03:46, stop: 18/05/2005 12:07:34 does not seem like a valid relay. Since you're not going to explain why, I'm guessing it's not really a problem. Now who can give me a hint of pushing Event-Timestamp like May 18 2005 12:08:18 MSD into oracle TIMESTAMP WITH TIME ZONE field? Edit oraclesql.conf to use the query you want. That's why the queries are configurable. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Event-Timestamp attribute
Hi. The Event-Timestamp attribute is now (according to yesterday CVS snapshot) in separate file dictionary.rfc2869. This RFC says the attribute to be unsigned integer. Why is it date in dictionary.rfc2869? 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 ... -- Alexander - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Event-Timestamp attribute
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
