[RADIATOR] Help Radiator wimax Session Table

Heikki Vatiainen hvn at open.com.au
Mon Jul 2 04:22:42 CDT 2012


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.


More information about the radiator mailing list