[RADIATOR] Unsupported EAP Response 26

michael.filz at zv-extern.fraunhofer.de michael.filz at zv-extern.fraunhofer.de
Thu Sep 12 13:10:04 UTC 2019

On Thu, 2019-09-12 at 13:38 +0300, Heikki Vatiainen wrote:
> On 12/09/2019 10.15, michael.filz at zv-extern.fraunhofer.de wrote:
> > I probably should have known better, but I redacted a bit too much.
> > There are actually two handlers (and AuthBy sections) for the inner
> > authentication that need to distinguish between different inner
> > identity formats. I basically have
> > 
> > <Handler TunnelledByPEAP=1,EAP-Message=/<PATTERN 1>/i>
> > ...
> > 
> > <Handler TunnelledByPEAP=1,EAP-Message=/<PATTERN 2>/i>
> > ...
> > 
> > I can omit the EAP-Message part, but then the first handler will be
> > used in all instances and authentication with the second pattern
> > fails.
> > Any ideas?
> Do you think you could add an attribute in the inner request to make 
> inner TunnelledByPEAP handler selection easier? In other words, not
> to 
> rely on EAP-Message contents but something that you set, for
> example, 
> with PreHandlerHook within the outer Handler's AuthBy that has PEAP 
> configured as an EAPType.

In theory yes, but after several ours of browsing both the
documentation, web and some of the sources I still can't figure out how
to access the inner request's user name (which I need to distinguish
the handlers). Can that even be done?

> In your other message with comparison between 4.18 and 4.23, they
> both 
> show that the final EAP-MSCHAP-V2 message (type 26) is processed by 
> outer Handler that has only EAPType PEAP configured.
> Your configuration is not typical because it does delivers EAP
> messages 
> belonging to the same EAP authentication exchange to different
> Handlers. 
> With 4.18 the final handshake was allowed to finish because EAP 26
> had 
> already started. With 4.23 each AuthBy only processes EAP messages
> for 
> the types it's EAPType lists. This is normally not a problem because
> EAP 
> for a certain type is always handled by the same AuthBy. With a 
> configuration like you have, EAP starts with type 26 enabled AuthBy
> but 
> then gets switched to an AuthBY that does only type 25 (PEAP).

Thanks for the explaination.


More information about the radiator mailing list