The RadiusNT services runs using the "radius" account. The DSN is "Radius",
using "sa" for the login. Should these be set differently?
> One thing
> that might affect is is double-check your data directory is pointing to
> wherever your RadiusNT installion is, and make sure the mib.txt is in
> there. If RadiusNT can't find the mib.txt, the SNMP thread will fail,
> and so will the SNMP checking. Remember, the RadiusNT service starts
> in the sytem32 directory, not the c:\radius directory (or whatever).
I tried this out several times today after typing in "c:\radius" into the
RadiusNT Admin and restarting RadiusNT.
I tested the SNMP concurrency checking--sometimes it worked; sometimes it
caused RadiusNT to hang with the following error being displayed on the
screen:
Initialization of the dynamic link library c:\winnt\system32\user32.dll
failed. The process is terminating abnormally.
All subsequent authentications (by regular customers as well as me) failed
because of Radius timeout. I had to stop RadiusNT and remove the
"c:\radius" that I entered into the Admin before restarting
RadiusNT--otherwise, the same problem would have occurred again at some
point.
Here's what the debug info reported (for the connections that caused
RadiusNT to hang):
radrecv: Request from host c72cc20e code=1, id=58, length=105
User-Name = "test"
Password = "-\270\337\011D\301\\015Mi="
NAS-Identifier = 199.44.194.14
NAS-Port = 20116
NAS-Port-Type = Async
User-Service = Framed-User
Framed-Protocol = PPP
State = ""
Caller-Id = "8509420655"
NAS-Port-DNIS = "8772090"
Acct-Session-Id = "303453165"
rad_authenticate_ODBC()
SQL Statement: Select DateDiff(Minute, GetDate(), DateAdd(Day,
(ma.Extension+ma.OverDue+1), maExpireDate)), DateDiff(Minute, GetDate(),
DateAdd(Day, sa.Extension+1, saExpireDate)), sa.AccountID, sa.AccountType,
sa.Password, sa.Login, sa.Shell, sa.LoginLimit, ma.Balance, ma.OverLimit