I agree it would be best if the EAP sub-modules could return RLM_MODULE codes. However, I didnt want to do anything to rlm_eap that would break the other sub-modules. Currently, the rlm_eap_* authenticate functions return 1 for EAP_OK and 0 for EAP_INVALID. My thought was to add a third return code (2?) for EAP_HANDLED (a new enum value in rlm_eap.h). This would require changes in eap.c, and a patch in eap_authenticate to return RLM_MODULE_HANDLED in that case. The downside is that we'll have three different sets of return codes where we really only need one (the RLM_MODULE codes) but the other code is preserved that way. From your last response I suspect you would rather use the sane approach, but I thought I'd double check because I want to stay compatible with later Freeradius versions.
Dave
AlanDeKok wrote:
Dave Mason <[EMAIL PROTECTED]> wrote:
This may be an easy one but I wanted to double check with the list. I have an EAP type that requires dropping any Access-Request/EAP-Response with certain invalid attribute values. To do this, do I modify eap_authenticate in rlm_eap.c to return RLM_MODULE_HANDLED in this case? This would require me to modify eaptype_select, eaptype_call, etc. to return a new value (EAP-NOOP?). RLM_MODULE_HANDLED appears to be the only return code that does nothing; that is, doesnt send Access-Reject.
The EAP module shouldn't be defining it's own return codes, which are essentially identical to the RLM_MODULE return codes. Step one would be fixing rlm_eap so that the return codes are sane. After that, the question of what to return when, and how to handle the return codes becomes much easier.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
