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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
