Re: [RadiusNT] radius bug?

Josh Hillman ( (no email) )
Wed, 5 Apr 2000 15:55:42 -0400

From: Dale E. Reed Jr. <daler@iea-software.com>
> RadiusNT has internal code to ignore 32 is 4 is received (regardless of
> the name) so that you can name both 32 and 4 NAS-Identifier. Are you
> just trying to store both fields, or is there a specific goal here?

I was just trying to store both fields, that's all. If there's no way to do
it, then I'll just have to wipe out the field in the Calls table.

Josh

> Josh Hillman wrote:
> >
> > I added another column to our Calls table called "NASID" to correspond
with
> > an entry in the RadAttributes table: RadAttributeID=32, Name='NAS-ID',
> > Type=0, RadVendorID=0, RadVendorType=0. This is actually supposed to be
> > "NAS-Identifier", but it can't be named that because Emerald and
RadiusNT
> > need that name associated with attribute 4, which is supposed to be
> > "NAS-IP-Address".
>
> A dictionary just interprets the numbers to names. There is no
> requirement
> that a RADIUS server even have a dictionary, or name the attributes to
> what
> the RFC has.
>
> > Anyway, the problem is that RadiusNT can see the new column and displays
> > info for it when running radius -x15, however it does not make an
attempt to
> > insert that data into the Calls table, eventhough everything matches and
> > RadiusNT has been restarted. The column name doesn't even appear in the
SQL
> > statement. I've tried varying names for this both in RadAttributes and
> > Calls, but it doesn't seem to make a difference--it just never tries to
> > insert the data into the Calls table for that one field. Other Calls
> > column-additions have never done this before.
> >
> > The NASID column in Calls is varchar(17), nullable
> >
> > Does RadiusNT have some kind of problem dealing with attribute 32 when
it
> > comes to the SQL statement?

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