ttls/gtc + perl
aland at deployingradius.com
Sat Jan 9 11:54:20 CET 2010
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, 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
> ++[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
> 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?
More information about the Freeradius-Devel