But why

2 Oct 2019

      I'm getting this debug output when trying to authenticate from an iPad:
...
Wed Oct  2 17:57:23 2019 : Debug: (10) eap: Peer sent packet with method
EAP NAK (3)
Wed Oct  2 17:57:23 2019 : Debug: (10) eap: Found mutually acceptable type
MSCHAPv2 (26)
Wed Oct  2 17:57:23 2019 : Debug: (10) eap: Calling submodule eap_mschapv2
to process data
Wed Oct  2 17:57:23 2019 : Debug: (10) eap_mschapv2: Issuing Challenge
Wed Oct  2 17:57:23 2019 : Debug: (10) eap: Sending EAP Request (code 1)
ID 2 length 43
This is the content of the eap module:

eap {
...
default_eap_type = ttls
    timer_expire     = 60
    ignore_unknown_eap_types = no
    cisco_accounting_username_bug = no
    max_sessions = ${max_requests}
    md5 {
    }
    leap {
    }
    gtc {
        auth_type = PAP
    }
    tls-config tls-common {
        private_key_file = ${certdir}/deusto.key
        certificate_file = ${certdir}/deusto.pem
        dh_file = ${certdir}/dh
        ca_path = ${cadir}
        cipher_list = "DEFAULT"
        cipher_server_preference = no
        ecdh_curve = "prime256v1"
        cache {
            enable = no
        }
        verify {
        }
        ocsp {
            enable = no
            override_cert_url = yes
            url = "http://127.0.0.1/ocsp/"
        }
    }
    tls {
        tls = tls-common
    }
    ttls {
        tls = tls-common
        default_eap_type = pap
        copy_request_to_tunnel = no
        use_tunneled_reply = no
        virtual_server = "inner-tunnel"
    }
    peap {
        tls = tls-common
        default_eap_type = gtc
        copy_request_to_tunnel = no
        use_tunneled_reply = no
        virtual_server = "inner-tunnel"
    }
    mschapv2 {
    }
}
Pretty much standard. I expect TTLS + PAP, not MSCHAPv2

Is this a normal outcome?
Why iOS doesn't try PAP?
Having a User-Password attribute doesn't serve as a hint for the server
when looking for a mutually acceptable type?

Regards,
Alberto

But why

Alberto Martínez Setién