Bug 1241930 - Can't authenticate to wpa/wpa2 wifi access point
Summary: Can't authenticate to wpa/wpa2 wifi access point
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: wpa_supplicant
Version: 22
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1244188 1245766 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-10 12:50 UTC by Kevin Havener
Modified: 2017-02-24 09:25 UTC (History)
31 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-18 20:41:48 UTC


Attachments (Terms of Use)

Description Kevin Havener 2015-07-10 12:50:50 UTC
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.

Comment 1 Wallace Hermano 2015-07-16 00:07:26 UTC
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.

Comment 2 Major Hayden 2015-07-17 13:15:18 UTC
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 <eliad@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.benji@intel.com>
    Signed-off-by: Eliad Peller <eliad@wizery.com>
_______________________________________________

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

Comment 3 Dan Williams 2015-07-17 15:11:22 UTC
(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

Comment 4 Dan Williams 2015-07-17 15:19:31 UTC
(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.

Comment 5 Dan Williams 2015-07-17 16:41:56 UTC
(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

Comment 6 Major Hayden 2015-07-17 17:57:18 UTC
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

Comment 7 Kevin Havener 2015-07-20 14:45:30 UTC
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

Comment 8 Virgilio 2015-08-18 15:01:42 UTC
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.

Comment 9 Hannes Ovrén 2015-08-21 16:44:13 UTC
I can further confirm that downgrading wpa_supplicant to 2.3.3 allowed me to immediately connect to eduroam.

Comment 10 Redacted 001 2015-08-24 12:43:04 UTC
I can confirm the same behavior. Immediately after downgrading the wpa_supplicant to 2.3.3 allowed me to connect to our company WIFI.

Comment 11 Luiz Pegoraro 2015-09-03 13:45:43 UTC
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.

Comment 12 Kent Engström 2015-09-03 13:56:27 UTC
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.

Comment 13 Luiz Pegoraro 2015-09-08 12:46:42 UTC
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.

Comment 14 Germano Massullo 2015-09-11 09:55:33 UTC
*** Bug 1244188 has been marked as a duplicate of this bug. ***

Comment 15 Germano Massullo 2015-09-11 10:44:17 UTC
Lastest wpa supplicant working with WPA Enterprise connections:
wpa_supplicant-2.3-3.fc22.x86_64

Comment 16 David Koppelman 2015-09-11 13:15:10 UTC
(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

Comment 17 Ville Skyttä 2015-10-02 16:50:33 UTC
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.

Comment 18 Ville Skyttä 2015-10-02 16:51:16 UTC
*** Bug 1245766 has been marked as a duplicate of this bug. ***

Comment 19 Michael Voetter 2015-10-14 00:54:02 UTC
(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)

Comment 20 Fedora Admin XMLRPC Client 2015-10-14 14:50:20 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 21 Wallace Hermano 2015-10-15 10:40:30 UTC
I'm testing Fedora 23 beta but i can't downgrade the wpa_supplicant.

Comment 22 Nick Lowe 2015-10-15 11:45:55 UTC
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.

Comment 23 Nick Lowe 2015-10-15 11:46:40 UTC
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.)"

Comment 24 Nick Lowe 2015-11-07 13:01:14 UTC
This bug needs to be closed as NOTABUG.

Comment 25 Luiz Pegoraro 2015-11-16 16:43:51 UTC
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?

Comment 26 Nick Lowe 2015-11-16 16:50:38 UTC
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.

Comment 27 Luiz Pegoraro 2015-11-24 17:15:48 UTC
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

Comment 28 Michael Voetter 2015-11-25 20:57:19 UTC
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.

Comment 29 Luiz Pegoraro 2015-11-26 09:42:45 UTC
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?

Comment 30 Vincent P. 2015-11-26 20:52:11 UTC
(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.

Comment 31 Eran B. 2015-11-30 09:01:55 UTC
(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.

Comment 32 Vincent P. 2015-11-30 21:49:52 UTC
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.

Comment 33 Alberto Salvia Novella 2015-12-16 17:20:10 UTC
Also reported in <https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588>.

Comment 34 Luiz Pegoraro 2015-12-18 16:50:36 UTC
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.

Comment 35 Kevin Havener 2015-12-18 18:13:43 UTC
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.

Comment 36 Dan Williams 2015-12-18 20:41:48 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.