[RADIATOR] Help Radiator wimax Session Table

[Heikki Vatiainen]

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: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au] On
> Behalf Of Heikki Vatiainen
> Sent: Friday, 29 June 2012 11:00 PM
> To: radiator at open.com.au
> 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 <hvn at open.com.au>

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.