On Wed, Sep 5, 2012 at 9:47 AM, opensource@tigusoft.pl <opensource@tigusoft.pl> wrote:
users can not log in, from radius logs it would appear as if chilli login form for the user sends the password in some encrypted format (eap?)
Nope
while Radius only wants to use it as cleartext (despite configuration "authorize{...}" section allowing other types, as it is default). The radius secret is the same in radius and chilli.
Most likely they're not the same.
Radius logs show:
root@hotspot:/etc/freeradius# freeradius -X FreeRADIUS Version 2.1.10, for host x86_64-pc-linux-gnu, built on Nov 14 2010 at 21:12:30 (...)
You cut the log. Don't do that unless you absolutely know what you're doing. In this case, the actual access-request packet received is important
WARNING: Unprintable characters in the password. Double-check the shared secret on the server and the NAS!
Most likely that's the problem. If you DON'T cut the debug log, you'll be able to see what FR thinks the shared secret should be, and you can double-check it in your NAS. Often user edit the wrong file, thinking they've set the correct shared secret, when in fact they haven't.
Why Auth-Type was found to be PAP
It's determined from whatever the NAS sends
, is it said in the RADIUS packet?
If you see User-Name and User-Password in access-request packet, then it's PAP. That's why I said access-request packet is important. Don't cut it.
# egrep -v " *#" /etc/freeradius/clients.conf | egrep -v "^ *$"
client localhost { ipaddr = 127.0.0.1 secret = testing123 require_message_authenticator = no }
What does the debug say? Also, is the NAS REALLY localhost? i.e. you run chillispot in the SAME server as FR? -- Fajar