Hi, * Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> [2010-09-24 22:33:14+0100]:
I wish it was that simple! It seems that when I do "use_tunneled_reply = yes" and although the authentication with FR succeeds, the 4-way handshake between the client (wpa_supplicant 0.7.3) and the access point (hostapd 0.7.2) fails with wpa_supplicant reporting :
/me does not recall saying enable 'copy_request_to_tunnel = yes'.
State: ASSOCIATED -> 4WAY_HANDSHAKE [snipped unread log] EAPOL: Received EAP-Packet frame
It seems that the Access Point realizes that the identity in FR's reply has changed (from the outer identity to the inner one) and somehow the client doesn't like this and doesn't reply to the 1st message of the 4th way handshake. Instead it sends an EAPOL start message and a full authentication restarts with the same outcome.. and then again and again.
Have you considered comparing the difference in the RADIUS packets going to-and-fro in both cases; the one where authentication works and the one where it does not? What do you see? Most would suggest you look at section 3 of RFC2548... *sigh*
It seems that using unlang to change the reply to the outer identity of the initial request is not just for not revealing the privacy of the client but seems to be mandatory....
Read Section 5.1 of RFC2865 before jumping to conclusions with no evidence...
Any easier solution?
I could think of some, but most are unprintable. Cheers -- Alexander Clouter .sigmonster says: For every vision there is an equal and opposite revision.