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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to