(RADIATOR) RADIUS Attrib 28 (Idle-Timeout) default?

[Martin Wallner]

> -----Original Message-----
> From: Claudio Lapidus [mailto:clapidus at gmail.com] 
> Sent: Montag, 23. Jänner 2006 17:02
> To: Martin Wallner
> Cc: Hugh Irvine; radiator at open.com.au
> Subject: Re: (RADIATOR) RADIUS Attrib 28 (Idle-Timeout) default?
> 
> Hello Martin,
> 
> On 1/23/06, Martin Wallner <Martin.Wallner at eunet.co.at> wrote:
> > Mon Jan 23 13:47:52 2006: DEBUG: Query is: 'SELECT 
> password, checkattr, replyattr FROM subscribers WHERE 
> lower(username)='in9878'':
> 
> It looks like your reply attributes (including Idle-Timeout) 
> are coming from the database. What happens if you issue the 
> same query manually from a SQL prompt? Is the Idle-Timeout 
> attribute present in the response?

Claudio, 

thanks for the input..

In this setup, it can come either from the database or from the 'AddToReplyIfNotExist' clause, which is overwritten by the value in database, if there is an explicid result concerning the attribute. Sadly, neither in the database, nor in the AddToReplyIfNotExist stanza is 'Idle-Timeout' to find... 

My problem is, that RADIATOR seems to send Idle-Timeout=0 in EVERY successful Access-Reply, even if it's not configured to... This is a misinterpretation of RFC, IMHO, but normally it don't does anything bad, only in this case, where CISCO-TAC explicitely asked to remove Attrib 28 for testing purposes (as shown in the mails before, the Authentication process is terminated by the router, after the Access Request is sent, 'Accept' + the bundle of settings from RADIATOR is received and when processing ... yes, of cause ... 'Idle-Timeout' .... post-RADIUS in the Authentication sequence of the IOS...) 

=mw=

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.