On May 20, 2015, at 5:34 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
On 05/20/2015 05:21 PM, Alan DeKok wrote:
On May 20, 2015, at 5:16 PM, J Kephart <jkephart@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