RE: [RadiusNT] caching problems in RadiusNT 3.0

Austin, Gary D ( (no email) )
Fri, 02 Jun 2000 07:49:29 -0400

I have sort of a similar problem. I have left all the cache settings blank
and get a similar result. The difference is when you look at my debug it
gives the user name and the bad password message but when you look at the
USER: it has a bunch of special characters in it and the DATABASE: has the
correct one. I use radlogin to check but have yet to get any good requests.
This is driving me crazy.

-----Original Message-----
From: Andrew Fort [mailto:afort@staff.powerup.com.au]
Sent: Friday, June 02, 2000 2:56 AM
To: 'radiusnt@iea-software.com'
Subject: [RadiusNT] caching problems in RadiusNT 3.0

Hi,
I'm fairly new to this software, so if someone knows of a list article which
describes the problems I'm experiencing, please let me know. I have only
been able to find one person asking about caching settings, with no answers
:)

Basically, I'm wondering what are "regular", "sane" settings for the Cache
settings in RadiusNT Pro v3.0? Below is a problem relating to caching and
datbase lookups.

I'm using MSSQL 7, and it seems that with the defaults (all blank fields in
the administrator on the Cache section), I cannot get users to authenticate
(at all).

When I set the "Init load" to a high enough value (say, 90 days), a full
debug produces the line..

"71765 ODBC users loaded"

OK, sofar so good. However, when I change a password for one of those users
in the DB, the cached entry seems to win (forever).

What settings dictate the behaviour of the caching?

I'd like to have new password changes propogated out within 15 minutes - at
the moment I build the MasterAccounts/SubAccounts table every couple of
hours from an export process on another database, so the LastModified date
is updated regularly -- will this affect things?

It seems that when the RadiusNT software goes to check a user in the
database, rather than from its cache, it does this.. (log extract)

radrecv: Request from host ca8be332 (Test) code=1, id=242, length=86
NAS-Identifier = 202.139.2xx.xx
NAS-Port = 122
NAS-Port-Type = 5
User-Name = "abc"
Caller-Id = "202.139.23x.xx"
Password = "b=\351'h7\033\351\203Q\346\337\202\331\245\374"

SQL Statement: {CALL RadGetUser('abc',NULL)}

Sending Reject of id 242 to ca8be332 (UUNET) Jun 01 16:31:19 2000 [NOTICE]:
User: abc Bad Password user:test database:test2
Resp Time: 10 Auth: 2/3 -> 5 Acct: 0/0/0 -> 1

So in the above info, the database password for user "abc" is really "test",
but RadiusNT still thinks it is "test2".

However - it has done a query:

SQL Statement: {CALL RadGetUser('abc',NULL)}

But why does it send NULL for the password (that stored procedure will
naturally return 0 rows)??

Is this a PAP/CHAP issue? In the example above, I'm telnetting into the RAS
and logging in for an EXEC session (on the AS5300), but this is just
testing. When doing PPP/PAP logins from the RAS ISDN/dialup ports, it does
the same thing.

At the moment, I'm setting the "init load" setting high, and restarting the
server every X minutes (via 'net stop radiusnt'; 'net start radiusnt') in
the task scheduler - a hack which works (reload forces the entries to be
re-cached), but a dirty, dirty hack.

Anyone got any ideas or need more info to help me out?

Kind Regards,

Andrew Fort
Network Engineer
WebCentral Webhosting

For more information about this list (including removal) go to:
http://www.iea-software.com/support/maillists/liststart

For more information about this list (including removal) go to:
http://www.iea-software.com/support/maillists/liststart