On 06/30/2012 08:51 AM, Adam O'Reilly wrote: > The key_expires field doesn't seem to be very helpful here are a few > examples: > > key_expires: 10 > key_expires: 2147483647 > key_expires: 621 > key_expires: 400 > > Can you explain how I would derive if the key is expired or not.
The values look incorrect. Currently they should be something like 1341222735 (timestamp for Mon, 02 Jul 2012 09:52:15 GMT). Also, 2147483647 is 2^31 - 1 which is a curious number too. It's maximum value a signed 32 bit integer can hold. Try running Radiator with Trace 4 to see what time stamps are generated and updated/inserted into the database. Heikki > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Heikki Vatiainen > Sent: Friday, 29 June 2012 11:00 PM > To: [email protected] > Subject: Re: [RADIATOR] Help Radiator wimax Session Table > > On 06/29/2012 03:56 AM, Adam O'Reilly wrote: > >> We are investigating a problem on our wimax sessions table: device_session >> >> As it is getting quite large is there an option to clean up this table >> when the wimax session is torn down. > > Radiator does not have a built-in cleanup for the old entries, so you > would need e.g., a cron job for this. Column key_expires is set to > time() + KeyLifetime so you could consider cleaning up old rows based on > this column. > -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
