[RADIATOR] EAP TTLS issue

[Heikki Vatiainen]

On 22.11.2021 15.54, Dubravko Penezic wrote:

> I found in my DEBUG log follow :
> 
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571159: DEBUG: Handling with EAP: code 
> 2, 111, 17, 21
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571182: DEBUG: Response type 21
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571225: DEBUG: EAP TTLS data, 26, 111, 
> 109
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571271: DEBUG: EAP TTLS SSL_accept 
> result: -1, 6, 26
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571370: ERR: EAP TTLS error: -1, 6, 26,
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571456: DEBUG: EAP Failure, elapsed 
> time 0.095699
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571502: DEBUG: EAP result: 1, EAP TTLS 
> error:
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571524: DEBUG: AuthBy LDAP2 result: 
> REJECT, EAP TTLS error:
> 7f6a07d0 Mon Nov 22 14:49:40 2021 571565: INFO: Access rejected for 
> anonymous: EAP TTLS error:
> 
> just numerical code without error message, any clue ?

The current release logs TLS values, EAP codes, types, etc. with 
translation to human readle names in many more cases.

With this case, it's likely that TTLS failed already with the previous 
request/response round and the error is visible earlier in the log. 
These entries just show the final controlled failure that finishes the 
failed authentication.

You could check if there are warnings or errors in the logs within the 
couple of previous seconds.

> Server in authentication part use LDAP/SASL and EAP-TTLs/PAP .

This seems to be EAP-TTLS failing TLS handshake. Might be a problem with 
client not trusting server's certificate, for example. Because it was 
still calling SSL_accept, I don't think it was able to complete TLS 
handshake.

Thanks,
Heikki

-- 
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software