[RADIATOR] Unsupported EAP Response 26

Heikki Vatiainen hvn at open.com.au
Thu Sep 12 10:38:58 UTC 2019

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 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).

In short: my suggestion is to add a tag attibute to inner requests with 
PreHandlerHook within outer AuthBy and then use this attribute with 
TunnelledByPEAP=1 instead of EAP-Message.


Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.

More information about the radiator mailing list