Hi, * Panagiotis Georgopoulos <[email protected]> [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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
