Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
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?
Yes I did, although I mostly concentrated on the 4-way handshake of the client because this is where it is failing compared to without session resumption. The end-client does not follow up the 1st message of the 4-way handshake of the NAS, but decides to restart the full authentication.
It's worth always running tcpdump on the RADIUS server and looking at what is spat out on the wire; can be easier than trawling the FreeRADIUS output when you need to compare two authentication runs. Handy as a initial pass to give you a hint at what is wrong.
Anyway, so what I thought to do is to go to the post-auth section of my inner-server and add the following to remove the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes added by the inner-server and let the default add its own.
update reply { MS-MPPE-Recv-Key !* 0x00 MS-MPPE-Send-Key !* 0x00 }
Is the logic behind this fine or do you reckon it might break something else in the future?
Remote 'eap' from the inner server, I think this is linked to your pap/mschap modules noop'ing as the request is already primed for passing to the eap module as eap is added additional MS-MPPE keys. If you need an inner-eap (say for EAP-GTC, but then we would need Alan to apply a patch to make GTC useful</grumble>) then you should place that *after* pap/chap/mschap iirc. Here is my inner-auth (the ldap bits I left there as you might be interested in them, however others might like the outer:Cleartext-Password 'override' and want to also palm the error handling): ---- server auth { authorize { if ((outer.request:EAP-Message)) { update outer.request { User-Name := "%{request:User-Name}" } update reply { User-Name := "%{request:User-Name}" } } validate_username suffix if ((outer.request:EAP-Message) && Realm != "%{config:local.MY.realm}") { update outer.reply { Reply-Message := "Realm is '%{Realm}' on Inside" } reject } # if the password is passed to us use it, otherwise yank it from LDAP if ((outer.request:Cleartext-Password)) { update control { Cleartext-Password := "%{outer.request:Cleartext-Password}" } } else { ldap-login # some accounts are glitched and do not have a UP :( if (ok && !(control:Cleartext-Password)) { update outer.reply { Reply-Message := "No eDirectory UP" } reject } } pap chap mschap update reply { Auth-Type := "%{control:Auth-Type}" } } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MSCHAP { mschap } } } ---- Cheers -- Alexander Clouter .sigmonster says: The road to Hades is easy to travel. -- Bion