On 01:29 AM, Phil Mayers wrote:
On 07/07/11 14:43, Nitin Bhardwaj wrote:
Thanks Phil.
I found this recent patch added to 2.x, regarding inner-MSCHAP broken: https://lists.freeradius.org/pipermail/freeradius-users/2011-April/msg00295....
Yes, that's what I was thinking of.
I think this patch fixed the original issue, but the mschapv2 callback is not preserving *all* the attributes received from the home server. Any ideas on how to fix mschap_postproxy ?
It is hard. When the plain MSCHAP response comes back (as an Access-Accept) it has to be turned into an EAP-MSCHAPv2 Access-Challenge. The PEAP attribute-saving code does not look at Access-Challenge packets - only Access-Accept.
Basically, mschap_postproxy would need to save the attributes, then insert them in the final Access-Accept.
Another thing, this patch is not carried over to the 3.x branch and mschap_postproxy in both 2.x and 3.x are almost same (except for some DEBUG statements), so there must be something else different between 2.x and 3.x - which makes this work in 3.x and not in 2.x!!
Are you sure this is working in 3.x?
If 3.x is missing the above patch, post-proxy should fail completely; the Access-Accept won't be re-written to an EAP-MSCHAP access-challenge, and EAP should fail. Phil,
My mistake. I checked again - The 3.x is working only with the Intel's supplicant client (which even 2.x works with the patch applied), not with either native Windows' client (both on same Windows XP) or Juniper's Odyssey client ! I guess Intel's supplicant is more permissive (and non-conforming to the RFCs :). I had not tried more than one supplicants earlier with 3.x. Hence 2.x and 3.x behaviour is identical (failure!).
The (untested) patch below might help on 2.1.x:
https://github.com/philmayers/freeradius-server/commit/3c1ed71cde100268dba57...
...or for 3.x:
https://github.com/philmayers/freeradius-server/commit/6877b70f442536c93ed09...
Thanks for the patches, I'll give them a shot and report back.