Alexander Clouter wrote:
I first of all implemented everything nicely with just a straight forward non-EAP Access-Challenge approach; using rlm_perl to dish out a State attribute[1], the Reply-Message and of course to check the User-Password returned. This works great for pam_radius_auth.
Because you manage the State attribute...
As you can see nothing exciting. Now in the authorize section of the Perl module I wrote, when I send the Reply-Message challenge I return RLM_MODULE_HANDLED as the return code. The problem is when I do this I get: ---- ++[gtc-trial.perl] returns handled } # server gtc-trial [ttls] Got tunneled reply code 0
You need to set the reply code, which isn't currently possible with the Perl module.
Changing it to RLM_MODULE_OK lets it pass through and everything starts to work, but it feels wrong; also as I would have to add difficult code paths for EAP and non-EAP connections.
I'm not sure what you mean by that... for non-EAP sessions, make sure the previous config is used. For EAP, use the EAP config.
It's as if the fake-request stuff does not support RLM_MODULE_HANDLED?
It does. But when the EAP module returns "handled", it also sets the reply code.
On a separate note I found out the hard way then passing 'State' back as a Reply attribute causes the EAP state machine to find two State attributes flying around rather than just the one it generates (am I understanding this correctly?).
Yes. The EAP module generates && tracks its own State. Don't add another one, or it will get confused.
If I am having to opt for a slightly different code path for my Perl module's authorize section (OK for EAP and HANDLED for non-EAP) is it safe to assume EAP is keeping everything in order?
What doesn't that mean?
I am just using the State attribute to indicate that the challenge has been issued to the user and to avoid validating 'trash'; for example in the case of when using the Challenge-Response functionality found in mod_auth_radius. I see in ttls.c:process_reply() there are a number of probably relevant FIXME's on something that could be applicable?
Probably not. Alan DeKok.