Wily's wpasupplicant frequently fails on WPA enterprise networks

[Stéphane Graber]

Ever since I upgraded from vivid to wily on my laptop, I'm running into problems when connecting to my home WPA2 enterprise network.

Typically the first connection immediately after the driver is loaded works as expected, however any further reconnection and the occasional roaming between APs cause wpasupplicant to freeze entirely requiring me to kill it and most often also reload my wireless driver to get things working again.

## A failed (hanging) association looks like:
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> (wlan0): Activation: (wifi) connection 'stgraber.net-secure' has security, and secrets exist. No new secrets needed.
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'ssid' value 'stgraber.net-secure'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'scan_ssid' value '1'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'key_mgmt' value 'WPA-EAP'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'eap' value 'TLS'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'fragment_size' value '1300'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'ca_cert' value '/home/stgraber/data/certs/stgraber-radius/ca.crt'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'private_key' value '/home/stgraber/data/certs/stgraber-radius/castiana.p12'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'private_key_passwd' value '<omitted>'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'identity' value 'castiana'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'bgscan' value 'simple:30:-65:300'
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: added 'proactive_key_caching' value '1'
Sep 30 23:31:06 castiana NetworkManager[25815]: <warn> Connection disconnected (reason -3)
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> (wlan0): supplicant interface state: associated -> disconnected
Sep 30 23:31:06 castiana NetworkManager[25815]: <warn> Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnected: This interface is not connected: disconnect.
Sep 30 23:31:06 castiana NetworkManager[25815]: <warn> Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnected: This interface is not connected: disconnect.
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> Config: set interface ap_scan to 1
Sep 30 23:31:06 castiana NetworkManager[25815]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: SME: Trying to authenticate with 24:a4:3c:c8:69:03 (SSID='stgraber.net-secure' freq=2412 MHz)
Sep 30 23:31:07 castiana kernel: [102903.079940] wlan0: authenticate with 24:a4:3c:c8:69:03
Sep 30 23:31:07 castiana kernel: [102903.085128] wlan0: send auth to 24:a4:3c:c8:69:03 (try 1/3)
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: Trying to associate with 24:a4:3c:c8:69:03 (SSID='stgraber.net-secure' freq=2412 MHz)
Sep 30 23:31:07 castiana NetworkManager[25815]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Sep 30 23:31:07 castiana kernel: [102903.086942] wlan0: authenticated
Sep 30 23:31:07 castiana kernel: [102903.090103] wlan0: associate with 24:a4:3c:c8:69:03 (try 1/3)
Sep 30 23:31:07 castiana NetworkManager[25815]: <info> (wlan0): supplicant interface state: authenticating -> associating
Sep 30 23:31:07 castiana kernel: [102903.101962] wlan0: RX AssocResp from 24:a4:3c:c8:69:03 (capab=0x411 status=0 aid=1)
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: Associated with 24:a4:3c:c8:69:03
Sep 30 23:31:07 castiana kernel: [102903.103701] wlan0: associated
Sep 30 23:31:07 castiana NetworkManager[25815]: <info> (wlan0): supplicant interface state: associating -> associated
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=CA/ST=Quebec/L=Montreal/O=stgraber.net/OU=Internal Infrastructure/CN=stgraber.net Root CA/name=stgraber.net Infrastructure Root <email address hidden>' hash=87b9750baadddac7f05164d7fde3a0eb3d3efe0c948b430a3ecd093c629956e9
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=CA/ST=Quebec/L=Montreal/O=stgraber.net/OU=Internal Infrastructure/CN=radius/name=stgraber.net Infrastructure Root <email address hidden>' hash=1fc5a4237c625f445a8eaf3794d4ee475d47dd7be31301a0215ee9701dee46e0
Sep 30 23:31:07 castiana wpa_supplicant[25653]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=CA/ST=Quebec/L=Montreal/O=stgraber.net/OU=Internal Infrastructure/CN=freeradius01/name=stgraber.net Internal Infrastructure Radius <email address hidden>' hash=9fa224ec6e74510d80257cc4dd43e660e0015642959b2fdea8995cbc71c6abf8
Sep 30 23:31:07 castiana wpa_supplicant[25653]: l2_packet_send - sendto: Message too long
Sep 30 23:31:28 castiana wpa_supplicant[25653]: message repeated 3 times: [ l2_packet_send - sendto: Message too long]
Sep 30 23:31:31 castiana NetworkManager[25815]: <warn> (wlan0): Activation: (wifi) association took too long
Sep 30 23:31:31 castiana NetworkManager[25815]: <info> (wlan0): device state change: config -> failed (reason 'no-secrets') [50 120 7]
Sep 30 23:31:31 castiana NetworkManager[25815]: <info> NetworkManager state is now CONNECTED_LOCAL
Sep 30 23:31:31 castiana kernel: [102927.404913] wlan0: deauthenticating from 24:a4:3c:c8:69:03 by local choice (Reason: 3=DEAUTH_LEAVING)
Sep 30 23:31:31 castiana NetworkManager[25815]: <warn> (wlan0): Activation: failed for connection 'stgraber.net-secure'
Sep 30 23:31:31 castiana NetworkManager[25815]: <info> (wlan0): device state change: failed -> disconnected (reason 'none') [120 30 0]
Sep 30 23:31:31 castiana wpa_supplicant[25653]: wlan0: CTRL-EVENT-DISCONNECTED bssid=24:a4:3c:c8:69:03 reason=3 locally_generated=1
Sep 30 23:31:31 castiana NetworkManager[25815]: <info> Device 'wlan0' has no connection; scheduling activate_check in 0 seconds.
Sep 30 23:31:31 castiana NetworkManager[25815]: <warn> Connection disconnected (reason -3)
Sep 30 23:31:31 castiana NetworkManager[25815]: <info> (wlan0): supplicant interface state: associated -> disconnected
Sep 30 23:31:31 castiana kernel: [102927.422121] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sep 30 23:31:31 castiana NetworkManager[25815]: <warn> Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnected: This interface is not connected: disconnect.

## A successful association (as seen after restart wpasupplicant) looks like:
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> (wlan0): Activation: (wifi) connection 'stgraber.net-secure' has security, and secrets exist. No new secrets needed.
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'ssid' value 'stgraber.net-secure'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'scan_ssid' value '1'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'key_mgmt' value 'WPA-EAP'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'eap' value 'TLS'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'fragment_size' value '1300'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'ca_cert' value '/home/stgraber/data/certs/stgraber-radius/ca.crt'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'private_key' value '/home/stgraber/data/certs/stgraber-radius/castiana.p12'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'private_key_passwd' value '<omitted>'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'identity' value 'castiana'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'bgscan' value 'simple:30:-65:300'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: added 'proactive_key_caching' value '1'
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> Config: set interface ap_scan to 1
Oct 1 00:21:49 castiana kernel: [105943.745716] wlan0: authenticate with 24:a4:3c:c8:69:13
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: SME: Trying to authenticate with 24:a4:3c:c8:69:13 (SSID='stgraber.net-secure' freq=5805 MHz)
Oct 1 00:21:49 castiana kernel: [105943.756236] wlan0: send auth to 24:a4:3c:c8:69:13 (try 1/3)
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> (wlan0): supplicant interface state: inactive -> authenticating
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: Trying to associate with 24:a4:3c:c8:69:13 (SSID='stgraber.net-secure' freq=5805 MHz)
Oct 1 00:21:49 castiana kernel: [105943.842803] wlan0: authenticated
Oct 1 00:21:49 castiana kernel: [105943.845837] wlan0: associate with 24:a4:3c:c8:69:13 (try 1/3)
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: Associated with 24:a4:3c:c8:69:13
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> (wlan0): supplicant interface state: authenticating -> associating
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
Oct 1 00:21:49 castiana kernel: [105943.846886] wlan0: RX AssocResp from 24:a4:3c:c8:69:13 (capab=0x11 status=0 aid=1)
Oct 1 00:21:49 castiana kernel: [105943.848105] wlan0: associated
Oct 1 00:21:49 castiana kernel: [105943.848134] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> (wlan0): supplicant interface state: associating -> associated
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=CA/ST=Quebec/L=Montreal/O=stgraber.net/OU=Internal Infrastructure/CN=stgraber.net Root CA/name=stgraber.net Infrastructure Root <email address hidden>' hash=87b9750baadddac7f05164d7fde3a0eb3d3efe0c948b430a3ecd093c629956e9
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=CA/ST=Quebec/L=Montreal/O=stgraber.net/OU=Internal Infrastructure/CN=radius/name=stgraber.net Infrastructure Root <email address hidden>' hash=1fc5a4237c625f445a8eaf3794d4ee475d47dd7be31301a0215ee9701dee46e0
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=CA/ST=Quebec/L=Montreal/O=stgraber.net/OU=Internal Infrastructure/CN=freeradius01/name=stgraber.net Internal Infrastructure Radius <email address hidden>' hash=9fa224ec6e74510d80257cc4dd43e660e0015642959b2fdea8995cbc71c6abf8
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
Oct 1 00:21:49 castiana wpa_supplicant[9608]: nl80211: Unexpected encryption algorithm 5
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> (wlan0): supplicant interface state: associated -> 4-way handshake
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: WPA: Key negotiation completed with 24:a4:3c:c8:69:13 [PTK=CCMP GTK=CCMP]
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-CONNECTED - Connection to 24:a4:3c:c8:69:13 completed [id=0 id_str=]
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> (wlan0): supplicant interface state: 4-way handshake -> completed
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'stgraber.net-secure'.
Oct 1 00:21:49 castiana NetworkManager[9615]: <info> (wlan0): device state change: config -> ip-config (reason 'none') [50 70 0]
Oct 1 00:21:49 castiana gnome-session[1907]: (deja-dup-monitor:5926): GLib-CRITICAL **: Source ID 1789 was not found when attempting to remove it
Oct 1 00:21:49 castiana wpa_supplicant[9608]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=9000

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: wpasupplicant 2.4-0ubuntu2
ProcVersionSignature: Ubuntu 4.2.0-11.13-generic 4.2.1
Uname: Linux 4.2.0-11-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.19-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Oct 1 00:24:02 2015
InstallationDate: Installed on 2015-04-23 (160 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
SourcePackage: wpa
UpgradeStatus: No upgrade log present (probably fresh install)

[Kevin (kevin-redhat-bugs)]

Description of problem: After updating to wpa_supplicant 2.4-3 on July 1, was unable to connect to my corporate wifi access point. Subsequent downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this is a wpa_supplicant bug

Version-Release number of selected component (if applicable): wpa_supplicant 2.4-3

How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS authentication that has been working for well over a year now. Fails. Downgrade to 2.3-3 and it works again.

Steps to Reproduce: See above
1. Select network in NetworkManager
2. Does not connect
3. Keeps asking for password

Actual results:

From /etc/wpa_supplicant.log after upgrade:

wlp12s0: SME: Trying to authenticate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Trying to associate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Associated with e0:1c:41:34:19:e9
wlp12s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
wlp12s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp12s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlp12s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authori
ty' hash=c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authori
ty' hash=c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.g
odaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287' hash=09ed6e991fc3273d8fea317d339c0204
1861973549cfa6e1558f411f11211aa3
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/OU=Domain Control Validated/CN=cicsnc.org' hash=598c9bcc63d9e114262181d14
dfed5372381b7ae0eb762e701b689b0e309f9b7
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:www.cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:osx.cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:osx2.cicsnc.org
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
wlp12s0: Authentication with e0:1c:41:34:19:e9 timed out.
wlp12s0: CTRL-EVENT-DISCONNECTED bssid=e0:1c:41:34:19:e9 reason=3 locally_generated=1
wlp12s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CICS" auth_failures=1 duration=10 reason=AUTH_FAILED
wlp12s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CICS" auth_failures=2 duration=35 reason=CONN_FAILED

After downgrade:

wlp12s0: Trying to associate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Associated with e0:1c:41:34:19:e9
wlp12s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp12s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
wlp12s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlp12s0: ...

[Wallace (wallace-redhat-bugs)]

I'm using Fedora 22.
After updating the package wpa_supplicant 2.3 to 2.4 can not connect to the wireless network (PEAP-MSCHAPv2, no CA Certificate).

Please see this thead http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Internal-radius-server-incompatibility-with-the-new-wpa/td-p/236602

After downgrade to 2.3 it works again.

[Major (major-redhat-bugs)]

I ran through a git bisect this morning and found that once this patch was applied, I couldn't hop on my corporate Aruba wifi network:

https://w1.fi/cgit/hostap/commit/?id=674f6c073f6f7cd9e04e5f117710f03d5e09ad63

_______________________________________________
commit 674f6c073f6f7cd9e04e5f117710f03d5e09ad63
Author: Eliad Peller <email address hidden>
Date: Wed Oct 22 08:03:56 2014 -0400

    WMM AC: Add basic ADDTS/DELTS sending functions

    Add basic implementation for ADDTS and DELTS sending
    functions.

    wpas_wmm_ac_addts() will send ADDTS request public action,
    containing TSPEC (traffic stream specification) with
    the given params.

    wpas_wmm_ac_delts() will look for the saved tspec with
    the given tid, and send DELTS public action for it.

    (Handling of ADDTS response and actually configuring the admission
    control params will be added in following patches.)

    Signed-off-by: Moshe Benji <email address hidden>
    Signed-off-by: Eliad Peller <email address hidden>
_______________________________________________

A simple 'git revert' was insufficient as additional patches have piled into these same files afterwards. :/

[Dan (dan-redhat-bugs)]

(In reply to Kevin Havener from comment #0)
> Description of problem: After updating to wpa_supplicant 2.4-3 on July 1,
> was unable to connect to my corporate wifi access point. Subsequent
> downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this is a
> wpa_supplicant bug
>
>
> Version-Release number of selected component (if applicable): wpa_supplicant
> 2.4-3
>
>
> How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS
> authentication that has been working for well over a year now. Fails.
> Downgrade to 2.3-3 and it works again.

This appears to be an OpenSSL issue, not a wpa_supplicant one:

SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

for exmaple, see:

https://bbs.archlinux.org/viewtopic.php?id=198796
http://alicevixie.blogspot.com/2015/06/dh-key-too-small.html

[Dan (dan-redhat-bugs)]

(In reply to Wallace Hermano from comment #1)
> I'm using Fedora 22.
> After updating the package wpa_supplicant 2.3 to 2.4 can not connect to the
> wireless network (PEAP-MSCHAPv2, no CA Certificate).
>
> Please see this thead
> http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Internal-
> radius-server-incompatibility-with-the-new-wpa/td-p/236602
>
> After downgrade to 2.3 it works again.

Your issue is likely due to wpa_supplicant enabling TLSv1.2 support (in response to recent attacks against SSLv3, TLSv1.0, and TLSv1.1, like the recent Firefox updates that disabled SSLv3 and TLSv1.0 negotiation). Unfortunately, not all RADIUS servers are prepared for that, and they accept the TLSv1.2 connection but generate a mismatching key than the supplicant does. That bug is in the RADIUS server...

There are some patches floating around that will detect this condition and fall back to the less-secure TLSv1.1 automatically, and we'll probably have to add those to Fedora until the RADIUS server vendors like Cisco, Aruba, etc catch up and fix their products.

[Dan (dan-redhat-bugs)]

(In reply to Dan Williams from comment #3)
> (In reply to Kevin Havener from comment #0)
> > Description of problem: After updating to wpa_supplicant 2.4-3 on July 1,
> > was unable to connect to my corporate wifi access point. Subsequent
> > downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this is a
> > wpa_supplicant bug
> >
> >
> > Version-Release number of selected component (if applicable): wpa_supplicant
> > 2.4-3
> >
> >
> > How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS
> > authentication that has been working for well over a year now. Fails.
> > Downgrade to 2.3-3 and it works again.
>
> This appears to be an OpenSSL issue, not a wpa_supplicant one:
>
> SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
> OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL
> routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
> wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
>
> for exmaple, see:
>
> https://bbs.archlinux.org/viewtopic.php?id=198796
> http://alicevixie.blogspot.com/2015/06/dh-key-too-small.html

More info: wpa_supplicant 2.4 may trigger this where 2.3 would not, becuase 2.4 enables some new ciphers for use with TLSv1.2, and the server may have enabled DH only for those ciphers that are now enabled.

The options are to either get your network admins to fix the DH key issue by using something > 768 bits, or to disable TLSv1.2 for now until they fix it.

But as a test, here's a wpa_supplicant with TLSv1.2 disabled by default. If you could test it on your network where you get the "dh key too small" error to see if that fixes the issue, then great, we can proceed with a more general solution. But if it doesn't fix the issue, then we'll need to dig a bit deeper and there may not be a general fix.

http://koji.fedoraproject.org/koji/taskinfo?taskID=10392924

[Major (major-redhat-bugs)]

I tried the koji build from the last comment and I'm unable to connect. With debug wpa_supplicant logs, I get:

SSL: SSL_connect:error in SSLv2/v3 read server hello A
SSL: SSL_connect:error in SSLv3 read finished A
SSL: SSL_connect:error in SSLv3 read finished A

[Kevin (kevin-redhat-bugs)]

I also tried the Koji build. Got the same error as I originally submitted:

SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

I

[Virgilio (virgilio-redhat-bugs)]

I can also confirm that a downgrade of the wpa_supplicant package to version 2.3.3 on Fedora 22 x86_64 makes it possible again to connect to a WPA2 Enterprise/PEAP/MSCHAPV2 network, like eduroam.

[Hannes (hannes-redhat-bugs)]

I can further confirm that downgrading wpa_supplicant to 2.3.3 allowed me to immediately connect to eduroam.

[Gregor (gregor-redhat-bugs)]

I can confirm the same behavior. Immediately after downgrading the wpa_supplicant to 2.3.3 allowed me to connect to our company WIFI.

[Luiz (luiz-redhat-bugs)]

I can confirm the same behavior.

I downgraded to 2.3.3 and I was able to connect successfully to connect to the wifi, but then I upgraded the kernel to 4.1.6 and it installed an wpa_supplicant-gui and some other wpa packages, and it stopped working again.

Can I get some help identifying if the issue is from the same root cause?

Because the wpa_supplicant-gui has the same 2.4.4 version of the wpa_supplicant and I tried to downgrade the *-gui one and it failed, due to not having package available.

[Kent (kent-redhat-bugs)]

FYI: I have seen the same (or at least very similar problems). Upgrading to 2.4-3 or 2.4-4 broke my eduroam connection. Downgrading to 2.3-3 again made it work.

I talked to the people running the authentication server (Radiator) used when I log in to eduroam. They upgraded OpenSSL and a related Perl module on the server. After that, eduroam survived an upgrade to 2.4-4 on my laptop.

[Luiz (luiz-redhat-bugs)]

Solved the issue removing the wpa_supplicant, and it removed anaconda and anaconda-gui. Then I re-installed the wpa_supplicant, NetworkManager-wifi, and downgraded the wpa_supplicant.

If someday has a fix I would be very happy to un-block wpa_supplicant packages from my dnf exceptions.

[Germano (germano-redhat-bugs)]

*** Bug 1244188 has been marked as a duplicate of this bug. ***

[Germano (germano-redhat-bugs)]

Lastest wpa supplicant working with WPA Enterprise connections:
wpa_supplicant-2.3-3.fc22.x86_64

[David (david-redhat-bugs)]

(In reply to Germano Massullo from comment #15)
> Lastest wpa supplicant working with WPA Enterprise connections:
> wpa_supplicant-2.3-3.fc22.x86_64

Just to avoid confusion:

The lastest wpa supplicant that works with WPA Enterprise connections is
wpa_supplicant-2.3-3.fc22.x86_64

[Stéphane Graber (stgraber)]

Same issue happened again after I downgraded to vivid's version...

Now rebooting my laptop on a vivid kernel to confirm it's a kernel bug and not a wpasupplicant bug.

[Ville (ville-redhat-bugs)]

eduroam broke for me with 2.4 as well. I tried upgrading to 2.5 locally but it remained similarly broken. Works with 2.3-3.

[Ville (ville-redhat-bugs)]

*** Bug 1245766 has been marked as a duplicate of this bug. ***

[Jean-Louis Dupond (dupondje)]

I'm also running Wily since a week, and I'm unable to connect to my corporate WiFi anymore.
I did a downgrade to the wpa-supplicant version in Debian Sid (2.3-2.1) and the connection works fine again.

[Jean-Louis Dupond (dupondje)]

Arch had same issue it seems:
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/wpa_supplicant&id=7562b98bd83fe5bce43e6952e0e922e7791e18b5

[Michael (michael-redhat-bugs)]

(In reply to Gregor Fuis from comment #10)
> I can confirm the same behavior. Immediately after downgrading the
> wpa_supplicant to 2.3.3 allowed me to connect to our company WIFI.

I had the same issue. The workaround with version 2.3.3 did the trick for me as well.

(In reply to Dan Williams from comment #4)
> Your issue is likely due to wpa_supplicant enabling TLSv1.2 support (in
> response to recent attacks against SSLv3, TLSv1.0, and TLSv1.1, like the
> recent Firefox updates that disabled SSLv3 and TLSv1.0 negotiation).
> Unfortunately, not all RADIUS servers are prepared for that, and they accept
> the TLSv1.2 connection but generate a mismatching key than the supplicant
> does. That bug is in the RADIUS server...

I can confirm that updating FreeRADIUS (server/network infrastructure) to version freeradius-2.2.6-6.el6_7.x86_64 fixed the issue with wpa_supplicant as well as a (probably similar) issue with android 6.0 as described here https://code.google.com/p/android/issues/detail?id=188867#c29

I am now running wpa_supplicant-2.4-4.fc22.x86_64 on fedora and can connect successful to a WiFi using PEAP-MSCHAPv2 (with and without a server certificate check against a CA Certificate)

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Wallace (wallace-redhat-bugs)]

I'm testing Fedora 23 beta but i can't downgrade the wpa_supplicant.

[Nick (nick-redhat-bugs)]

I wouldn't bother degrading client security by forcing TLS 1.1

The fact that Google have shipped with TLS 1.2 in Android 6.0 (Marshmallow) is quickly identifying and mopping up broken authentication servers.

[Nick (nick-redhat-bugs)]

I posted in the Google issue tracker:

" suspect that you all are hitting this issue because the new version of Android is now negotiating, correctly, with TLS 1.2 and you have a broken backend.

If so, this issue should be marked as being invalid.

This applies to anybody with WPA2-Enterprise/802.1X SSIDs backed by either FreeRADIUS 2.2.6 with all TLS-based EAP types, 2.2.6 through 2.2.8 with EAP-TTLS, 3.0.7 with all TLS-based EAP types, and 3.0.7 through 3.0.9 with EAP-TTLS, or Radiator 4.14 or later when used in conjunction with Net::SSLeay 1.52 or earlier.

These unfortunately experience a critical bug where they miscalculate session keying material, the MPPE keys, when the TLS 1.2 protocol is negotiated by EAP clients (supplicant).

Clients that negotiate with the TLS 1.2 protocol version in the TLS Client Hello will not be able to get a usable association to affected wireless networks.

Two MPPE keys, the MS-MPPE-Recv-Key (MasterReceiveKey) and MS-MPPE-Send-Key (MasterSendKey), are used to derive the Master Session Key (MSK). This is absolutely essential to get a usable association.

The mismatch occurs because the client derives the correct MSK and the AP derives a different, incorrect MSK due to the incorrectly calculated MPPE keys supplied in the RADIUS Access-Accept.

This is more of an acute issue as Red Hat ship with a broken FreeRADIUS 2.2.6 package in RHEL 6.7. There is an update now to address this: https://rhn.redhat.com/errata/RHBA-2015-1829.html

CentOS 6.7 is similarly affected as it derives from Red Hat's sources.

I should also mention that there is a difference between implementing/offering TLS 1.2 or not and being intolerant to it. It is the latter that is a problem with the introduction of TLS 1.2 for EAP.

The issue above, loosely, concerns intolerance because the subsequent MPPE keys generated are miscalculated.

Deployments that continue to offer just TLS 1.0 will continue to function correctly as TLS 1.0 will be negotiated by EAP clients (supplicants) despite it offering TLS 1.2 in the client hello in their default configuration. (TLS has a version negotiation mechanism, you just need an intersection of supported versions and cipher suites.)"

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthew Geier (matthew-sleeper)]

In my case it's not frequency fails - it always fails. On 3 separate WAP Enterprise SSIDs.

I understand that the WPA Supplicant people say this is a Radius server bug and not a supplicant bug. That may be true, but there is little chance of the offending radius servers on the WPA Enterprise networks I need to use being upgraded until this same bug bites Windows and MacOS. Until then as far as they are concerned it's a Linux bug and not their problem.

[Žygimantas Beručka (zygis)]

Just noting that installing version 2.1-0ubuntu7.2 from Vivid and pinning it works as workaround.

In addition, I tend to agree with comment #6 on the importance of having an adequate understanding of the severity of the issue. Nobody can expect and force all those faulty Radius servers to be upgraded by the companies, universities and other organisations just because the bug only hits Linux users.

[Nick (nick-redhat-bugs)]

This bug needs to be closed as NOTABUG.

[phlegm (daveshome)]

Same problem here. Can no longer connect to corporate wifi since upgrading

[Luiz (luiz-redhat-bugs)]

Hey Nick,

I am not using Android, I am using the Fedora 23 as an SO and this error is really annoying, I tried to check which TLS version I am using and still dont have any clue.

Can you help checking or to use the TLS that doesnt error out?

[Nick (nick-redhat-bugs)]

Anywhere that is using wpa_supplicant 2.4 or later without specific configuration to disable TLS 1.2 will hit this issue with affected RADIUS servers. TLS 1.2 is rightly enabled by default.

(Android Marshmallow uses such a version of wpa_supplicant).

You can certainly disable TLS 1.2 in the configuration for wpa_supplicant if you absolutely must get a usable connection.

Do so with phase1="tls_disable_tlsv1_2=1"

Ideally though you would seek to get the RADIUS server updates to a version that isn't broken.

[phlegm (daveshome)]

Confirmed that downgrading to wpa 2.1-0ubuntu7.2 fixes the issue for me on corporate network.

[Adam (ajacobs)]

Me too. Same problem, and downgrading fixes it for me too.

What exactly do the WPA Supplicant people think is wrong with the RADIUS servers? I can't find that anywhere online.

[Adam (ajacobs)]

Nevermind, I found the redhat bug with the RADIUS info.

[Luiz (luiz-redhat-bugs)]

I am trying to understand better the last choice, I could connect with the command line, but its kind of annoying still. My version of the freeradius is this
[~] $ sudo dnf info freeradius
Last metadata expiration check performed 3:05:10 ago on Tue Nov 24 12:08:27 2015.
Pacotes instalados
Name : freeradius
Arq. : x86_64
Epoch : 0
Versão : 3.0.8
Release : 3.fc23
Tam. : 3.4 M
Repo : @System
From repo : fedora

[Michael (michael-redhat-bugs)]

I'm not sure if I get you right. Are you using Fedora as a server operating system to provide radius authentication for your network infrastructure?

TLS1.2 is the currently newest and (hopefully) most secure version of the TLS protocol and therefore it is a good choice using it. So disabling TLS1.2 is a bad idea as stated in comment #26. Use a radius server version that implements TLS1.2 correctly instead.

Version 3.0.8 is affected when using EAP-TTLS as mentioned in comment #23 so if you have trouble use a different server version or a different EAP type.

If I've got you totally wrong and you are not the network operator ask your network operator to fix the problem and remove freeradius from your notebook/workstation.

[Luiz (luiz-redhat-bugs)]

Yeah, I am a software developer using Fedora as a workstation. Unfortunately my network administrators like Windows, the solution they provided me is to use Ubuntu. If I want to use Linux. I prefer Fedora because I use it since version 13.

I removed the freeradius. The command line is not connecting anymore.
Here is my log. Any thoughts?

Successfully initialized wpa_supplicant
wlp6s0: SME: Trying to authenticate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Trying to associate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Associated with 94:b4:0f:1b:bc:c5
wlp6s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp6s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp6s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA' hash=ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA' hash=c27fd4b85e96d3777c68ab7df6aa4e626bf3ff8c72b1ce81d1eb78babeb1a074
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF/C=US/O=securelogin.arubanetworks.com/OU=GT28470348/OU=See www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated - QuickSSL(R) Premium/CN=securelogin.arubanetworks.com' hash=47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
wlp6s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:securelogin.arubanetworks.com
wlp6s0: CTRL-EVENT-DISCONNECTED bssid=94:b4:0f:1b:bc:c5 reason=3 locally_generated=1
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=BR
wlp6s0: SME: Trying to authenticate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Trying to associate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Associated with 94:b4:0f:1b:bc:c5
wlp6s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp6s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp6s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA' hash=ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA' hash=c27fd4b85e96d3777c68ab7df6aa4e626bf3ff8c72b1ce81d1eb78babeb1a074
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF/C=US/O=securelogin.arubanetworks.com/OU=GT28470348/OU=See www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated - QuickSSL(R) Premium/CN=securelogin.arubanetworks.com' hash=47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
wlp6s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:securelogin.arubanetworks.com
wlp6s0: CTRL-EVENT-DISCONNECTED bssid=94:b4:0f:1b:bc:c5 reason=3 locally_generated=1
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=BR
wlp6s0: SME: Trying to authenticat...

[Vincent (vincent-redhat-bugs)]

(In reply to Luiz Pegoraro from comment #29)
> I am still wondering if the issue is on wpa_supplicant or on the hardware,
> because I know a guy who has another PC using Fedora 22 with wpa_supplicant
> 2.4 that connects in the network via NetworkManager.

For F22 with wpa_supplicant 2.4 check this bug too, it seems the openssl library version matters: https://bugzilla.redhat.com/show_bug.cgi?id=1276073

> Also that configuration of the phase1, Can I set somewhere in the
> NetworkManager so I don't have to run command lines to connect to the
> network?

I got it working (F23/wpa_supplicant-2.4-7/openssl-1.0.2d-2) with a custom wpa_supplicant config and some manual steps:
network={
 ssid="corpwifi"
 key_mgmt=WPA-EAP
 eap=PEAP
 phase1="peaplabel=auto tls_disable_tlsv1_2=1"
 phase2="auth=MSCHAPV2"
 identity="***"
 password="***"
}
Unfortunately, I couldn't get the above working with the Networkmanager (/etc/wpa_supplicant/wpa_supplicant.conf and ifcg-corpwifi). The config set in /etc/wpa_supplicant/wpa_supplicant.conf wasn't used.

[Eran (eran-redhat-bugs)]

(In reply to Vincent P. from comment #30)

Sorry for the rookie questions, but:
1. Did you change /etc/wpa_supplicant/wpa_supplicant.conf or did you replace it?
2. After the change in /etc/wpa_supplicant/wpa_supplicant.conf, how am I to connect if not by the Networkmanager?

Thanks

> (In reply to Luiz Pegoraro from comment #29)
> > I am still wondering if the issue is on wpa_supplicant or on the hardware,
> > because I know a guy who has another PC using Fedora 22 with wpa_supplicant
> > 2.4 that connects in the network via NetworkManager.
>
> For F22 with wpa_supplicant 2.4 check this bug too, it seems the openssl
> library version matters: https://bugzilla.redhat.com/show_bug.cgi?id=1276073
>
> > Also that configuration of the phase1, Can I set somewhere in the
> > NetworkManager so I don't have to run command lines to connect to the
> > network?
>
> I got it working (F23/wpa_supplicant-2.4-7/openssl-1.0.2d-2) with a custom
> wpa_supplicant config and some manual steps:
> network={
> ssid="corpwifi"
> key_mgmt=WPA-EAP
> eap=PEAP
> phase1="peaplabel=auto tls_disable_tlsv1_2=1"
> phase2="auth=MSCHAPV2"
> identity="***"
> password="***"
> }
> Unfortunately, I couldn't get the above working with the Networkmanager
> (/etc/wpa_supplicant/wpa_supplicant.conf and ifcg-corpwifi). The config set
> in /etc/wpa_supplicant/wpa_supplicant.conf wasn't used.

[Vincent (vincent-redhat-bugs)]

I'm not sure if this is the right place te respond, but hey..wth.

(In reply to Eran B. from comment #31)
> (In reply to Vincent P. from comment #30)
>
> Sorry for the rookie questions, but:
> 1. Did you change /etc/wpa_supplicant/wpa_supplicant.conf or did you replace
> it?
After I did some manual testing (see next answer), I tried to update /etc/wpa_supplicant.conf with my corpwifi config and reconnect via the Networkmanager. Unfortunately, it didn't work.

> 2. After the change in /etc/wpa_supplicant/wpa_supplicant.conf, how am I to
> connect if not by the Networkmanager?
I turned off wifi via the Networkmanager. I created a new wpa_supplicant.conf in /root/ and rand some manual commands:

1. Connect to wifi:
# wpa_supplicant -f /var/log/wpa_supplicant.log -dd -P /var/run/wpa_supplicant.pid -c wpa_supplicant.conf -Dwext -iwlp3s0

2. Get an IP:
# dhclient wlp3s0

After this you should get an IP.

During my tests I fiddled with 'rfkill list all', 'rfkill unblock wifi' and 'ip l set wlp3s0 up' too, but if you get an IP with the above steps, you don't need too.

[Scott Pakin (pakin)]

I have the same problem Downgrading to wpasupplicant 2.1-0ubuntu7 works for me on my corporate network.

[Christian Rank (c-rank)]

The logs submitted by the bug reporter contain lines like
Sep 30 23:31:07 castiana wpa_supplicant[25653]: l2_packet_send - sendto: Message too long

I had exactly the same problem, so I checked the MTU of my wireless interface and noticed that it was set to 1280.

After issuing
   ifconfig <wlan-interface> mtu 1500
the wpa connection works again.

But, after being connected some time, the MTU decreases again to 1280. The reason in my setup seems to be some strange behaviour of NetworkManager and IPv6:
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <info> address xxx.xxx.xxx.160
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <info> plen 23 (255.255.254.0)
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <info> gateway xxx.xxx.xxx.252
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <info> server identifier xxx.xxx.xxx.252
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <info> lease time 1200
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <info> nameserver 'xxx.xxx.xxx.253'
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <info> domain name 'xxx.de'
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <info> (wlp2s0): DHCPv4 state changed bound -> bound
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <warn> (wlp2s0): Lowering IPv6 MTU (1500) to match device MTU (0)
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <warn> (wlp2s0): IPv6 MTU (0) smaller than 1280, adjusting
Dec 7 13:46:31 rank-Latitude-E4310 NetworkManager[731]: <warn> (wlp2s0): Raising device MTU (0) to match IPv6 MTU (1280)

Since we have no IPv6 in our WLAN, I disabled IPv6 for the connection in NetworkManager. Unfortunately, this does not change anything - after the first DHCP renewal, the MTU is set to 1280 again ...

This calls for further investigation ...

[Christian Rank (c-rank)]

See also
https://bugs.launchpad.net/ubuntu/wily/+source/network-manager/+bug/1499827

[Christian Rank (c-rank)]

Setting the MTU for the WiFi connection in NetworkManager from "auto" to "1500 bytes" solves my problem.

[Alberto (alberto-redhat-bugs)]

Also reported in <https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588>.

[Christian Rank (c-rank)]

The corresponding bug in NetworkManager was fixed:
https://bugs.launchpad.net/ubuntu/wily/+source/network-manager/+bug/1499827/comments/12
Should solve this problem as well.

[Mathieu Trudel-Lapierre (cyphermox)]

For starters, if you're seeing this message: "l2_packet_send - sendto: Message too long", it likely means that you're hitting that MTU problem with NM, which has been fixed already as pointed out by Christian.

If you're hitting *any other* problem, please file *your own* bug, using the following command:

ubuntu-bug wpa

That way we will be able to look at each issue independently, and really untangle things. Otherwise it's nearly impossible to make sense of potentially many different issues in the same bug. The key is, one person, one bug, even if it looks the same to you, it doesn't mean it really is the same thing as someone else wrote in a comment.

It's a bit more involved than just the MTU issue. There indeed looks like there are some issues in wpasupplicant 2.4; but until separate bugs are filed, it's going to be really hard to fix them. Thanks to Jean-Louis for pointing out the Arch bug, which also links to http://lists.shmoo.com/pipermail/hostap/2015-April/032722.html and http://lists.shmoo.com/pipermail/hostap/2015-April/032723.html which are some of the relevant details to usual issues with 2.4. Once we have separate bugs filed against wpa for the various problems, we'll be able to solve them.

[Luiz (luiz-redhat-bugs)]

SOLVED TODAY!!! BY NETWORKMANAGER!! Just dnf update -y
I am so thrilled! Thanks you guys!

I guess it was a problem in firmwares, I looked into the logs and there were a lot of new packages for firmwares.

Thanks a lot, I guess saying by using Fedora 23, this can be closed now.

[Kevin (kevin-redhat-bugs)]

As the opener of this bug, I think it can be closed now. While other folks seem to have wireless problems, I don't think they are related to my problem which was fixed for me by an upgrade to our corporate wireless access points. It has continued to work after upgrading from F22 to F23 and a couple of iterations of wpa_supplicant as well.

[Dan (dan-redhat-bugs)]

Yeah, for TLSv1.2 issues updating the RADIUS server or corporate network is obviously the best choice. If that's not possible then the workaround with the supplicant config must be used, but the problem is at the RADIUS server.

[7oby (tobias-hain)]

Thanks Mathieu for separating the MTU issues from the PMK key mismatch problems during TLS 1.2 negociation.

I'm facing the latter: and tried to apply this patch:

"EAP-TLS/TTLS/PEAP workaround for incorrect TLS v1.2 MSK derivation"
http://lists.shmoo.com/pipermail/hostap/2015-July/033312.html
https://patchwork.ozlabs.org/patch/493119/

It does work to the extend that it recognizes the key mismatch problems with the Aruba Networks buggy TLS 1.2 implementation that I'm connecting to

"wpa_supplicant[1504]: wlan1: RSN: PMKID mismatch - authentication server may have derived different MSK?!"

According to the above mentioned patch Aruba ClearPass Policy Manager before 6.5.2 has those issues. However the walkaround doesn't seem to work - or I made a mistake appyling the patch. The hostap upstream code for which the patch has been developed differs to some extend from the ubuntu version one.

Therefore two walkarounds remain

a) downgrade wpasupplicant to version <= 2.3 lacking TLS v1.1 support

b) enforcing TLS 1.1 on wpasupplicant 2.4-0ubuntu3.2

$ cat wpa_supplicant.conf

network={
  ssid="YOUR_SSID_HERE"
  key_mgmt=WPA-EAP
  eap=PEAP
  identity="YOUR_USERNAME_HERE"
  password="YOUR_PASSWORD_HERE"
  phase1="tls_disable_tlsv1_2=1"
  phase2="auth=MSCHAPV2"
}

$ sudo service network-manager stop
$ sudo wpa_supplicant -i wlan1 -D wext -c ./wpa_supplicant.conf -dd
$ sudo dhclient wlan1

I didn't find a way to enforce TLS 1.1 via KDEs 5.x GUI interface. And neither to inject the settings directly into network-manager though I think that should work as well. Had to stop network-manager - it wouldn't work otherwise.