But why
Alberto Martínez Setién
alberto.martinez at deusto.es
Wed Oct 2 18:16:56 CEST 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
More information about the Freeradius-Users
mailing list