Access request always return reject

[James Kephart]

We're working on it.  Baby steps. :-|
----- Reply message -----
From: "Arran Cudbard-Bell" <a.cudbardb at freeradius.org>
To: "FreeRadius users mailing list" <freeradius-users at lists.freeradius.org>
Subject: Access request always return reject
Date: Wed, May 20, 2015 17:41


> On May 20, 2015, at 5:34 PM, J Kephart <jkephart at safetynetaccess.com> wrote:
>
> On 05/20/2015 05:21 PM, Alan DeKok wrote:
>> On May 20, 2015, at 5:16 PM, J Kephart <jkephart at safetynetaccess.com> wrote:
>>> We've just compiled FR 2.2.7 on a CentOS 6.6 system, preparatory to
>>> migrating from our old 2.1.12 release.  When we ran the initial test,
>>> under "radius -X," we got the expected reject, because there was no user
>>> named "test."  We then added that user to the users file (the only
>>> change we made), with just the username and cleartext-password, and ran
>>> the test again, and it still returned a reject.
>>>
>>> I'm posting the output from "radius -X" below.  We've essentially the
>>> same config on the older server, and we've never encountered the problem
>>> there, so it seems fairly obvious that something's wrong; we just can't
>>> tell what it is.  I do see that it says "++[reject] = reject", but I'm
>>> not seeing the cause.
>>  Something in the "authorize" section is rejecting the user.  It's happening right after the "eap" module is run.  That should help narrow it down a lot.
>>
>>> One note however:  In the output, at line 190, we see "server { # from
>>> file /usr/loc" followed by a bunch of gibberish.  I'm not sure that's a
>>> real concern, but it does seem odd.
>>  I think it was fixed already.
>>
>>> In any case, the debug output is below.  I'd appreciate it if someone
>>> could point me to the problem.
>>  See above.  Please also use "radiusd -X".  Adding "radiusd -Xx" and line numbers isn't necessary.
>>
>>  Alan DeKok.
>>
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> Thanks for the look, Alan.
>
> On the gibberish, this is from the latest 2.2.7 release that we just
> downloaded this afternoon.  Has the fix been made available in that source?

If it hasn't I vote against fixing it. v2.2.x is EOL, it is security fix only.

You should be upgrading to v3.0.8 if you want to continue to use a supported version.

Give it a year and the only response on the mailing list will be the same as v1.x.x users.

        UPGRADE

-Arran