Hi, I'm slapping together a OTP system to use with FreeRADIUS and for the EAP side of things I am using GTC to get the challenge to the user and the response back. 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. Then I moved onto the EAP side of things. The state of play is: TTLS -> GTC -> Perl The relevant bits of my config looks like: ---- eap gtc-trial.eap { .... gtc { challenge = "%{reply:Reply-Message}" auth_type = rfc2289 } ttls { default_eap_type = md5 copy_request_to_tunnel = no use_tunneled_reply = yes } .... } -- authorize { .... gtc-trial.perl gtc-trial.eap } authenticate { Auth-Type gtc-trial.eap { gtc-trial.eap } Auth-Type rfc2289 { gtc-trial.perl } } -- ---- 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 Reply-Message = "otp-md5 489 ch4230" [ttls] No tunneled reply was found for request 6 , and the request was not proxied: rejecting the user. [gtc-trial.eap] Handler failed in EAP/ttls rlm_eap_ttls: Freeing handler for user ac56@soas.ac.uk [gtc-trial.eap] Failed in EAP select ++[gtc-trial.eap] returns invalid Failed to authenticate the user. } # server gtc-trial Using Post-Auth-Type Reject ---- 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. ---- ++[gtc-trial.perl] returns ok [gtc-trial.eap] EAP packet type response id 1 length 6 [gtc-trial.eap] No EAP Start, assuming it's an on-going EAP conversation ++[gtc-trial.eap] returns updated Found Auth-Type = gtc-trial.eap +- entering group gtc-trial.eap {...} [gtc-trial.eap] Request found, released from the list [gtc-trial.eap] EAP NAK [gtc-trial.eap] EAP-NAK asked for EAP-Type/gtc [gtc-trial.eap] processing type gtc [gtc] expand: %{reply:Reply-Message} -> otp-md5 489 ch4230 ++[gtc-trial.eap] returns handled } # server gtc-trial [ttls] Got tunneled reply code 11 Reply-Message = "otp-md5 489 ch4230" EAP-Message = 0x01020017066f74702d6d64352034383920636834323330 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x2ab1156b2bb3138a6ec7c66d7216040d [ttls] Got tunneled Access-Challenge ++[gtc-trial.eap] returns handled } # server gtc-trial Sending Access-Challenge of id 57 to 77.75.106.34 port 1645 EAP-Message = 0x010a003f158000000035170301003060c61e58df7bb793b8bb0ff121a83f4c2e6709089d2806be79ba5b38f1188e918e1a23a26a5361cd919357ebf957b3b6 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x799072d07e9a671e00b9e884d1d4d75c ---- It's as if the fake-request stuff does not support RLM_MODULE_HANDLED? Of course I could be mis-understanding things completely and I should just stick with RLM_MODULE_OK...even for the non-EAP requests (however that *does* feel wrong). 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?). ---- [gtc-trial.eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled request EAP-Message = 0x020100060306 FreeRADIUS-Proxied-To = 127.0.0.1 [ttls] Sending tunneled request EAP-Message = 0x020100060306 FreeRADIUS-Proxied-To = 127.0.0.1 User-Name = "ac56@soas.ac.uk" State = 0x72666332323839 State = 0xa044d18fa045d5754a1bb165bbc5857d [snipped] [gtc-trial.eap] EAP packet type response id 1 length 6 [gtc-trial.eap] No EAP Start, assuming it's an on-going EAP conversation ++[gtc-trial.eap] returns updated Found Auth-Type = gtc-trial.eap +- entering group gtc-trial.eap {...} [gtc-trial.eap] Either EAP-request timed out OR EAP-response to an unknown EAP-request [gtc-trial.eap] Failed in handler ++[gtc-trial.eap] returns invalid Failed to authenticate the user. } # server gtc-trial [ttls] Got tunneled reply code 3 [ttls] Got tunneled Access-Reject [gtc-trial.eap] Handler failed in EAP/ttls rlm_eap_ttls: Freeing handler for user ac56@soas.ac.uk [gtc-trial.eap] Failed in EAP select ++[gtc-trial.eap] returns invalid Failed to authenticate the user. } # server gtc-trial Using Post-Auth-Type Reject ---- 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? 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? If you need any more information or the actual code, then do ask. Cheers [1] similarly to how Harry J Walsh was doing things: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg47425.h... -- Alexander Clouter .sigmonster says: No line available at 300 baud.