On Sun, 2007-09-16 at 22:08 +0100, Andrew Rowson wrote:
tnt@kalik.co.yu wrote:
Comment it out anyway. You are setting Auth-Type Local in SQL database then. If not in radcheck then in radgroupcheck.
Ivan Kalik Kalik Informatika ISP
I feel really stupid now. It was sitting there in radgroupcheck setting the auth-type to local.
ARGH.
Ok, regroup. The new output is in the same place as before (http://public.growse.com/radiusd.log) - it sets the auth-type to EAP
Sigh. Don't set the Auth-Type AT ALL. The only legitimate uses are: * setting it to Accept for PAP requests * setting it to Reject * setting it to the name of a specific instance where there are >1 of the same type of auth module with different configs (e.g. 2 different LDAPs or 2 different mschap) The "eap" module will itself detect the request is eap and (assuming the server is configured correctly, as it is by default) set the Auth-Type. By forcing it manually, you are guaranteeing that certain authentication configurations will fail.
and seems to issue the attributes (my cisco priv ones are there) ok. My laptop still doesn't get an IP address, but this may now be an issue with the AP.
Can I safely now say that freeradius is behaving correctly and the issue is now with the AP, or does the above output still point to a freeradius issue?
I don't know why you're returning: Cisco-AVPair = "shell:priv-lvl=15" Service-Type = Administrative-User ...to an access point EAP session; neither make any sense, and I suppose could be mucking things up, but most likely the problem lies with the supplicant rather than the AP. It may not like the SSL server certificate, though from what I can see it's not getting that far. Is the supplicant configured to do EAP-TLS? It's apparent you've done a serious amount of fiddling with the default configs. I suggest doing a default/clean install, and starting from the most basic - a user in the "users" file: username Cleartext-Password := "foobar" Check if they can authenticate. Then setup the sql module, put the above AND ONLY THE ABOVE entries in the database, and test again. Making once change at a time will allow you to pin down the problem; at the moment, there are lots of things it *could* be.