On 05/14/2011 10:08 AM, stentofon wrote:
The users connect through a chillispot captive portal, via HTTP. HTTPS causes too many problems with certificates, and the access point is unencripted anyway, so security is not the issue.
I initally thought that the hotspot clients were simply making mistakes, but i've been testing it all day with the iphone v blackberry and Windows 7 and i'm fairly certain the password is going in ok. I set the username and password to be sandra : sandra for simplicity, as the autocorrect should leave it alone. I also set up an account as 1234 : 1234 and this also failed only on the iphone.
For it to only affect Apple products, i had hoped that the debug message was going to show some rubbish in the username to prove that there was some
No; the packet is well-formed. The problem is that, in your failing case, the CHAP-Password is not valid for the given CHAP-Challenge and your plaintext password "sandra". That is, the client (Chilli) is sending invalid auth to FreeRADIUS.
issue with the input, but i can't see the issue when the debug message is confirming that the correct username and password were supplied.
That's not what the debug message says. I assume you're referring to this line: [chap] login attempt by "sandra" with CHAP password [chap] Using clear text password "sandra" for user sandra authentication. ...which means "I'm trying a login for 'sandra'. My (server-side) value for their clear text password is 'sandra'". It doesn't refer to anything the client sent (well, the username I guess). CHAP is a challenge-response method. The NAS (Chilli) never sends the password to FreeRADIUS. Instead, it sends: CHAP-Challenge = 16 random bytes CHAP-Password = 1 byte ID + md5(ID + password + challenge) The radius server then extracts the plaintext password from the SQL database, and the ID & challenge from the packet, computes it's own copy of CHAP-Password, and compares it to the packet. In your failing case, they don't match, so authentication is denied (I've confirmed this by doing the MD5 manually in python - it's definitely invalid. I tried a few trivial variations of the password too, so see if I could figure out what the client was using - no dice) I think the problem must be at the Chillispot end - it's breaking the CHAP somehow for iOS clients. Since you're not using HTTPS, you could try getting a packet capture of a working and failing login HTTP session, and compare the two in detail - I'd be looking for the POSTed form data, and any HTTP headers that might affect the interpretation e.g. character encodings. But this isn't really a FreeRADIUS problem I'm afraid.