Re: FW: Problems with Rads

Dale E. Reed Jr. ( (no email) )
Fri, 01 May 1998 11:16:02 -0700

Fox, Thomas wrote:
> I'm still unable to determine why my clients who have static
> IP's aren't receiving them. I've compared our production database
> to the sample, and all of the field names, etc. match. Can you
> please offer some guidance?
> User olgar should be receiving ip, but is being
> assigned from the pool

> olgar found on-line 0 time(s).
> CHECK Framed-Address = (0)
> CHECK Idle-Timeout = 600 (600)
> Loading radius defaults for this type...
> Framed-Protocol = PPP (1)
> User-Service = Framed-User (2)
> Session-Timeout = 14400 (14400)
> Framed-Compression = Frames-Compression (1)
> Idle-Timeout = 600 (600)
> Sending Ack of id 128 to d1b06ae9 ( Framed-Protocol
> = PPP
> User-Service = Framed-User
> Session-Timeout = 14400
> Framed-Compression = Van-Jacobsen-TCP-IP
> Idle-Timeout = 600

Note two things. First, the Framed-Address and Idle-Timeout should
*NOT* be check attributes, but you have them confgiured as such. If
you look at the last four lines above, you'll note there is NOT
a Framed-Address attribute being returned to the RADIUS client (hence
the assigned address by default).

Go into your RadConfigs table and double check the RadCheck column.
In almost ALL cases, unless the attribute is a check attribute (see
below) the column needs to NOT be a 1. If the column is a 1 for
that record, its a check attribute, not a reply attribute. For
a check attribute, RadiusNT will look for a matching attribute
in the authentication request and compare the two. If they don't
match, RadiusNT will reject the request (and put a check attribute
failur in the RadLogs for the user). Check attributes are *NOT*
sent in the list of reply attributes back to the NAS.

Side note, this is only relevant for RadiusNT 2.5 and above, since
RadiusNT 2.2 doesn't support check attributes in ODBC mode.

-- Dale E. Reed Jr.  (       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs Internet Solutions for Today  |