"use_tunnel_reply" not working in EAP-PEAP (Proxied as plain MSCHAPv2) in eap.conf
Nitin Bhardwaj
nbhardwaj at merunetworks.com
Thu Jul 7 15:43:35 CEST 2011
On 01:29 AM, Phil Mayers wrote:
>
>> In 3.x code, We are returning a RLM_MODULE_NOOP from eap_post_proxy() :
>> 582 /*
>> 583 * Just in case the admin lists EAP in post-proxy-type Fail.
>> 584 */
>> 585 if (!request->proxy_reply) return RLM_MODULE_NOOP;
>>
>> But we are not doing so in 2.1.11 code. We call the MSCHAPv2 callback,
>> i.e. mschap_postproxy(),
>> which might be wiping off the attributes.
>>
>> So, my question is: will adding this code patch to 2.x code prudent to
>> make it work ? Or we need to fix the
>> mschapv2 handler itself : mschap_postproxy() in rlm_eap_mschapv2.c,so
>> that it retains the extra attributes
>> sent by the RADIUS home server ?
>
> This code is complex and needs to be treated with care. There were
> changes recently related to failures when proxying PEAP inner as eap
> versus non-eap, and this code was implicated.
>
> Basically, be careful fiddling with it.
>
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.html
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 ?
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!!
Please throw some light !
--
Nitin.
More information about the Freeradius-Users
mailing list