Launchpad has imported 37 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1241930.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2015-07-10T12:50:50+00:00 Kevin wrote: 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: 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' 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' 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' wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/OU=Domain Control Validated/CN=cicsnc.org' EAP-MSCHAPV2: Authentication succeeded wlp12s0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully wlp12s0: WPA: Key negotiation completed with e0:1c:41:34:19:e9 [PTK=CCMP GTK=CCMP] wlp12s0: CTRL-EVENT-CONNECTED - Connection to e0:1c:41:34:19:e9 completed [id=0 id_str=] wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-62 noise=9999 txrate=6000 wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-59 noise=9999 txrate=81000 wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=135000 wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-59 noise=9999 txrate=6000 wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=121500 wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-61 noise=9999 txrate=135000 wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=6000 wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-61 noise=9999 txrate=6000 wlp12s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=135000 Expected results: The latter results are expected Additional info: PEAP, TLS, other authentication protocols produced the same ssl handshake error (dh key too small). "No CA required" was checked in NetworkManager in both cases, but I'm not sure if I snipped out the right part of the wpa_supplicant log in the failure case--I was trying everything. The SSL handshake failure was consistent under all attempts to authenticate no matter what drop downs/boxes were selected in NetworkManager under 2.4-3. Now that I have it working, I am loathe to break it again. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/0 ------------------------------------------------------------------------ On 2015-07-16T00:07:26+00:00 Wallace wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/1 ------------------------------------------------------------------------ On 2015-07-17T13:15:18+00:00 Major wrote: 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 <el...@wizery.com> 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 <moshe.be...@intel.com> Signed-off-by: Eliad Peller <el...@wizery.com> _______________________________________________ A simple 'git revert' was insufficient as additional patches have piled into these same files afterwards. :/ Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/2 ------------------------------------------------------------------------ On 2015-07-17T15:11:22+00:00 Dan wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/3 ------------------------------------------------------------------------ On 2015-07-17T15:19:31+00:00 Dan wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/4 ------------------------------------------------------------------------ On 2015-07-17T16:41:56+00:00 Dan wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/5 ------------------------------------------------------------------------ On 2015-07-17T17:57:18+00:00 Major wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/6 ------------------------------------------------------------------------ On 2015-07-20T14:45:30+00:00 Kevin wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/7 ------------------------------------------------------------------------ On 2015-08-18T15:01:42+00:00 Virgilio wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/8 ------------------------------------------------------------------------ On 2015-08-21T16:44:13+00:00 Hannes wrote: I can further confirm that downgrading wpa_supplicant to 2.3.3 allowed me to immediately connect to eduroam. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/9 ------------------------------------------------------------------------ On 2015-08-24T12:43:04+00:00 Gregor wrote: I can confirm the same behavior. Immediately after downgrading the wpa_supplicant to 2.3.3 allowed me to connect to our company WIFI. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/10 ------------------------------------------------------------------------ On 2015-09-03T13:45:43+00:00 Luiz wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/11 ------------------------------------------------------------------------ On 2015-09-03T13:56:27+00:00 Kent wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/12 ------------------------------------------------------------------------ On 2015-09-08T12:46:42+00:00 Luiz wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/13 ------------------------------------------------------------------------ On 2015-09-11T09:55:33+00:00 Germano wrote: *** Bug 1244188 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/14 ------------------------------------------------------------------------ On 2015-09-11T10:44:17+00:00 Germano wrote: Lastest wpa supplicant working with WPA Enterprise connections: wpa_supplicant-2.3-3.fc22.x86_64 Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/15 ------------------------------------------------------------------------ On 2015-09-11T13:15:10+00:00 David wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/16 ------------------------------------------------------------------------ On 2015-10-02T16:50:33+00:00 Ville wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/20 ------------------------------------------------------------------------ On 2015-10-02T16:51:16+00:00 Ville wrote: *** Bug 1245766 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/21 ------------------------------------------------------------------------ On 2015-10-14T00:54:02+00:00 Michael wrote: (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) Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/24 ------------------------------------------------------------------------ On 2015-10-14T14:50:20+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/25 ------------------------------------------------------------------------ On 2015-10-15T10:40:30+00:00 Wallace wrote: I'm testing Fedora 23 beta but i can't downgrade the wpa_supplicant. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/26 ------------------------------------------------------------------------ On 2015-10-15T11:45:55+00:00 Nick wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/27 ------------------------------------------------------------------------ On 2015-10-15T11:46:40+00:00 Nick wrote: 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.)" Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/28 ------------------------------------------------------------------------ On 2015-11-07T13:01:14+00:00 Nick wrote: This bug needs to be closed as NOTABUG. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/32 ------------------------------------------------------------------------ On 2015-11-16T16:43:51+00:00 Luiz wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/34 ------------------------------------------------------------------------ On 2015-11-16T16:50:38+00:00 Nick wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/35 ------------------------------------------------------------------------ On 2015-11-24T17:15:48+00:00 Luiz wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/39 ------------------------------------------------------------------------ On 2015-11-25T20:57:19+00:00 Michael wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/40 ------------------------------------------------------------------------ On 2015-11-26T09:42:45+00:00 Luiz wrote: 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 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 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. 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/41 ------------------------------------------------------------------------ On 2015-11-26T20:52:11+00:00 Vincent wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/42 ------------------------------------------------------------------------ On 2015-11-30T09:01:55+00:00 Eran wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/43 ------------------------------------------------------------------------ On 2015-11-30T21:49:52+00:00 Vincent wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/44 ------------------------------------------------------------------------ On 2015-12-16T17:20:10+00:00 Alberto wrote: Also reported in <https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588>. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/49 ------------------------------------------------------------------------ On 2015-12-18T16:50:36+00:00 Luiz wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/52 ------------------------------------------------------------------------ On 2015-12-18T18:13:43+00:00 Kevin wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/53 ------------------------------------------------------------------------ On 2015-12-18T20:41:48+00:00 Dan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588/comments/54 ** Changed in: hostap Status: Unknown => Fix Released ** Changed in: hostap Importance: Unknown => Medium ** Bug watch added: code.google.com/p/android/issues #188867 http://code.google.com/p/android/issues/detail?id=188867 ** Bug watch added: Red Hat Bugzilla #1276073 https://bugzilla.redhat.com/show_bug.cgi?id=1276073 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1501588 Title: Wily's wpasupplicant frequently fails on WPA enterprise networks To manage notifications about this bug go to: https://bugs.launchpad.net/hostap/+bug/1501588/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
