Wireless won't connect to WPA2 anymore

Hi,

I just installed Red Hat Enterprise Workstation 7.6 and my wireless card

03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)

doesn't want to associate with WPA2 WLANs anymore.

/var/log/wpa_supplicant.log says the following about it:


For my connection at home (just WPA2):

wlp3s0: Trying to associate with 9c:c7:a6:a2:61:0d (SSID='MYSSID' freq=2412 MHz)
wlp3s0: Associated with 9c:c7:a6:a2:61:0d
wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
wlp3s0: WPA: Failed to set GTK to the driver (alg=2 keylen=32 keyidx=1)
wlp3s0: RSN: Failed to configure GTK
wlp3s0: CTRL-EVENT-DISCONNECTED bssid=9c:c7:a6:a2:61:0d reason=1 locally_generated=1
wlp3s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="MYSSID" auth_failures=2 duration=20 reason=CONN_FAILED
wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE
wlp3s0: SME: Trying to authenticate with 9c:c7:a6:a2:61:0d (SSID='MYSSID' freq=2412 MHz)

And for my connection at work (WPA2 with PEAP & MSCHAPv2 [standard eduroam]):

wlp3s0: Trying to associate with 3c:0e:23:7d:6e:6f (SSID='eduroam' freq=5240 MHz)
wlp3s0: Associated with 3c:0e:23:7d:6e:6f
wlp3s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
wlp3s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 -> NAK
wlp3s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
OpenSSL: tls_connection_ca_cert - Failed to load root certificates error:00000000:lib(0):func(0):reason(0)
wlp3s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleS$
wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI$
wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI$
wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Niedersachsen/L=Oldenburg/O=Carl von Ossietzky Universitaet Oldenburg/$
wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius.uni-oldenburg.de
wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius.uol.de
wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius01.virt.uni-oldenburg.de
wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius02.virt.uni-oldenburg.de
wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius03.virt.uni-oldenburg.de
wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius04.virt.uni-oldenburg.de
OpenSSL: EVP_DigestInit_ex failed: error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips
EAP-TTLS/MSCHAPV2: Failed to derive response
EAP-TTLS: Phase2 Request processing failed
EAP-TTLS: failed to process early start for Phase 2
wlp3s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
wlp3s0: Authentication with 3c:0e:23:7d:6e:6f timed out.
wlp3s0: CTRL-EVENT-DISCONNECTED bssid=3c:0e:23:7d:6e:6f reason=3 locally_generated=1

From the logs and Googling, I highly assume that it has something to do with the security profile that was set during installation of Red Hat (which was USGCB - US Government Configuration Baseline. I think that baseline prevents users from

'using unsecure ciphers'

by blocking usage of said ciphers system-wide. If that is indeed the case: Why is it blocking WPA2-PSK and WPA2-Enterprise? Are those not 'secure ciphers'? How can I either set a 'secure cipher' to be used for wireless encryption or 'open the system up' to use the 'unsafe' ones?


Some further info:
The laptop in question also has Ubuntu Bionic and Windows 7 installed and wireless works perfectly fine in both. That's the main reason why I think it's just a matter of 'wrong' configuration of the Red Hat install.

Originally Posted by rokyo Hi, I just installed Red Hat Enterprise Workstation 7.6 and my wireless card 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34) doesn't want to associate with WPA2 WLANs anymore. /var/log/wpa_supplicant.log says the following about it: For my connection at home (just WPA2): wlp3s0: Trying to associate with 9c:c7:a6:a2:61:0d (SSID='MYSSID' freq=2412 MHz) wlp3s0: Associated with 9c:c7:a6:a2:61:0d wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE wlp3s0: WPA: Failed to set GTK to the driver (alg=2 keylen=32 keyidx=1) wlp3s0: RSN: Failed to configure GTK wlp3s0: CTRL-EVENT-DISCONNECTED bssid=9c:c7:a6:a2:61:0d reason=1 locally_generated=1 wlp3s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="MYSSID" auth_failures=2 duration=20 reason=CONN_FAILED wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE wlp3s0: SME: Trying to authenticate with 9c:c7:a6:a2:61:0d (SSID='MYSSID' freq=2412 MHz) And for my connection at work (WPA2 with PEAP & MSCHAPv2 [standard eduroam]): wlp3s0: Trying to associate with 3c:0e:23:7d:6e:6f (SSID='eduroam' freq=5240 MHz) wlp3s0: Associated with 3c:0e:23:7d:6e:6f wlp3s0: CTRL-EVENT-EAP-STARTED EAP authentication started wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE wlp3s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 -> NAK wlp3s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21 OpenSSL: tls_connection_ca_cert - Failed to load root certificates error:00000000:lib(0):func(0):reason(0) wlp3s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleS$ wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI$ wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI$ wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Niedersachsen/L=Oldenburg/O=Carl von Ossietzky Universitaet Oldenburg/$ wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius.uni-oldenburg.de wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius.uol.de wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius01.virt.uni-oldenburg.de wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius02.virt.uni-oldenburg.de wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius03.virt.uni-oldenburg.de wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius04.virt.uni-oldenburg.de OpenSSL: EVP_DigestInit_ex failed: error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips EAP-TTLS/MSCHAPV2: Failed to derive response EAP-TTLS: Phase2 Request processing failed EAP-TTLS: failed to process early start for Phase 2 wlp3s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed wlp3s0: Authentication with 3c:0e:23:7d:6e:6f timed out. wlp3s0: CTRL-EVENT-DISCONNECTED bssid=3c:0e:23:7d:6e:6f reason=3 locally_generated=1 From the logs and Googling, I highly assume that it has something to do with the security profile that was set during installation of Red Hat (which was USGCB - US Government Configuration Baseline. I think that baseline prevents users from 'using unsecure ciphers' by blocking usage of said ciphers system-wide. If that is indeed the case: Why is it blocking WPA2-PSK and WPA2-Enterprise? Are those not 'secure ciphers'? How can I either set a 'secure cipher' to be used for wireless encryption or 'open the system up' to use the 'unsafe' ones? Some further info: The laptop in question also has Ubuntu Bionic and Windows 7 installed and wireless works perfectly fine in both. That's the main reason why I think it's just a matter of 'wrong' configuration of the Red Hat install.

Read the release notes about this and how to work around it:
https://access.redhat.com/documentat...release_notes/

Also, since you're using RHEL, have you contacted RHEL support, since you're paying for it (RIGHT?)

Originally Posted by TB0ne Read the release notes about this and how to work around it: https://access.redhat.com/documentat...release_notes/ Also, since you're using RHEL, have you contacted RHEL support, since you're paying for it (RIGHT?)

I checked the release notes you linked but they don't say anything about wpa_supplicant, except some bug fixes and this:

Verification of signatures using the MD5 hash algorithm is disabled in Red Hat Enterprise Linux 7

It is impossible to connect to any Wi-Fi Protected Access (WPA) Enterprise Access Point (AP) that requires MD5 signed certificates. To work around this problem, copy the wpa_supplicant.service file from the /usr/lib/systemd/system/ directory to the /etc/systemd/system/ directory and add the following line to the Service section of the file:

Environment=OPENSSL_ENABLE_MD5_VERIFY=1 

Then run the*systemctl daemon-reload*command as root to reload the service file.

Important: Note that MD5 certificates are highly insecure and Red Hat does not recommend using them. (BZ#1062656)

But I can't imagine it's relevant because: Who would use MD5 nowadays for anything? I can't imagine Red Hat or Cisco (manufacturer of the routers at work) or AVM (manufacturer of my router at home) doing anything that involves MD5... at least I strongly hope so!

No, I don't pay for Red Hat but my university does with a campus license. I'm not sure if that qualifies me for customer support with Red Hat directly or if the university's IT support is responsible here? In either case: The uni's IT was unable to fix this.

Originally Posted by rokyo I checked the release notes you linked but they don't say anything about wpa_supplicant, except some bug fixes and this: Verification of signatures using the MD5 hash algorithm is disabled in Red Hat Enterprise Linux 7 It is impossible to connect to any Wi-Fi Protected Access (WPA) Enterprise Access Point (AP) that requires MD5 signed certificates. To work around this problem, copy the wpa_supplicant.service file from the /usr/lib/systemd/system/ directory to the /etc/systemd/system/ directory and add the following line to the Service section of the file: Environment=OPENSSL_ENABLE_MD5_VERIFY=1 Then run the*systemctl daemon-reload*command as root to reload the service file. Important: Note that MD5 certificates are highly insecure and Red Hat does not recommend using them. (BZ#1062656) But I can't imagine it's relevant because: Who would use MD5 nowadays for anything? I can't imagine Red Hat or Cisco (manufacturer of the routers at work) or AVM (manufacturer of my router at home) doing anything that involves MD5... at least I strongly hope so!

Did you try it?? And yes, there are some bugfixes and patches...have you applied them since...

No, I don't pay for Red Hat but my university does with a campus license. I'm not sure if that qualifies me for customer support with Red Hat directly or if the university's IT support is responsible here? In either case: The uni's IT was unable to fix this.

...you say you have support? If you have a support contract, you should at least be able to get the support ID, and contact RHEL yourself. That said, the "fail to set GTK.." message would indicate something with the wifi driver. Again, are all of the updates/patches applied??

Originally Posted by TB0ne Did you try it?? And yes, there are some bugfixes and patches...have you applied them since... ...you say you have support? If you have a support contract, you should at least be able to get the support ID, and contact RHEL yourself. That said, the "fail to set GTK.." message would indicate something with the wifi driver. Again, are all of the updates/patches applied??

Yes, the latest updates were applied right after installation. The connection problem persists. I'll write a ticket to our uni's tech support if they have a support ID for me.

Originally Posted by rokyo Yes, the latest updates were applied right after installation. The connection problem persists. I'll write a ticket to our uni's tech support if they have a support ID for me.

Ok, but past that...what kind of hardware are you using? The GTK message indicates some sort of problem with the wifi driver. And why are you using RHEL? Granted, you're using the workstation flavor, but my experience has been that RHEL is typically for servers. Support for 'consumer' hardware (bluetooth, wifi, sound, etc.), can be spotty.

Originally Posted by TB0ne Ok, but past that...what kind of hardware are you using? The GTK message indicates some sort of problem with the wifi driver. And why are you using RHEL? Granted, you're using the workstation flavor, but my experience has been that RHEL is typically for servers. Support for 'consumer' hardware (bluetooth, wifi, sound, etc.), can be spotty.

The laptop has the Intel Corporation Centrino Advanced-N 6205 WiFi card which is recognized by RHEL and shows up in 'lspci'. The graphical network manager thing in Gnome also recognizes the WiFi card and offers to list available networks but gives the above mentioned error when you actually try to connect to one.

I have to use RHEL since that's what runs on our university's compute cluster which I'll have to use in a future project. I installed RHEL on my private laptop to get familiar with the system since I've never used RHEL before, only CentOS but that's almost 10 years ago.

Originally Posted by rokyo The laptop has the Intel Corporation Centrino Advanced-N 6205 WiFi card which is recognized by RHEL and shows up in 'lspci'. The graphical network manager thing in Gnome also recognizes the WiFi card and offers to list available networks but gives the above mentioned error when you actually try to connect to one.

Right; so have you actually tried the workaround mentioned previously??? And this still points to a driver issue, either driver itself or firmware. Try downloading the firmware and following the instructions here: https://www.intel.com/content/www/us...etworking.html

That adapter is fairly old; have you tried a newer one?

I have to use RHEL since that's what runs on our university's compute cluster which I'll have to use in a future project. I installed RHEL on my private laptop to get familiar with the system since I've never used RHEL before, only CentOS but that's almost 10 years ago.

Sorry, makes no sense at all. You don't 'have to use RHEL'...your university's compute cluster's OS is totally irrelevant to your choice of OS on your laptop. Having RHEL there gets you nothing. And RHEL is nothing special; if you learn ANY distro of Linux, you'll know 99% of any other distro. There are a few utilities that are RHEL specific (as there are with Debian, Mint, Ubuntu, openSUSE, etc.), but they're trivial to use.

Again, since you're not paying for RHEL, I'd strongly suggest stopping where you are, and loading Mint, and chances are things will 'just work'.

Originally Posted by TB0ne Right; so have you actually tried the workaround mentioned previously??? And this still points to a driver issue, either driver itself or firmware. Try downloading the firmware and following the instructions here: https://www.intel.com/content/www/us...etworking.html

The workaround that requires activating MD5 which is explicitly NOT recommended to do by RedHat? No, I'm not going to do that.

I WILL, however, try the firmware! Thanks for the link!

That adapter is fairly old; have you tried a newer one?

No, since this adapter worked on any Linux distro I have tried so far, including RHEL7 if I don't select any SCAP profile during installation. So I strongly assume that it's only a matter of the security profile blocking something that is needed by wpa_supplicant. (And I hope it has nothing to do with MD5 because I'll rather make do without wireless before activating THAT ).

Sorry, makes no sense at all. You don't 'have to use RHEL'...your university's compute cluster's OS is totally irrelevant to your choice of OS on your laptop. Having RHEL there gets you nothing. And RHEL is nothing special; if you learn ANY distro of Linux, you'll know 99% of any other distro. There are a few utilities that are RHEL specific (as there are with Debian, Mint, Ubuntu, openSUSE, etc.), but they're trivial to use.

I think you misunderstood what I was saying. I installed it on my laptop so I can use it and play around with it in an environment where it's not critical if I break stuff, since it's my own personal hardware.

When the project starts, I will have to work DIRECTLY on the compute cluster where only RedHat is installed and I highly doubt the IT team will install Linux Mint or any other distro on their cluster just to make me happy.

Again, since you're not paying for RHEL, I'd strongly suggest stopping where you are, and loading Mint, and chances are things will 'just work'.

That's exactly the reason I need to use RHEL, because if things don't 'just work' there is the option of getting professional help from RedHat support since we are only using packages that are supplied by RedHat and therefore covered by their support and their online tutorials, etc. If I use Mint, Ubuntu or any other 'community's distro, there is no guarantee that anybody will or even can help me.

Originally Posted by rokyo The workaround that requires activating MD5 which is explicitly NOT recommended to do by RedHat? No, I'm not going to do that.

That is changing a text file and rebooting. And if you actually read the WHOLE sentence, it says it's not recommended to USE MD5...not that editing that file is bad.

No, since this adapter worked on any Linux distro I have tried so far, including RHEL7 if I don't select any SCAP profile during installation. So I strongly assume that it's only a matter of the security profile blocking something that is needed by wpa_supplicant. (And I hope it has nothing to do with MD5 because I'll rather make do without wireless before activating THAT ).

You said before that you've never used RHEL before...now you're saying you DID use it, and used RHEL 7 on this same hardware and it somehow worked fine? Yet the same RHEL 7 doesn't work now? And since this is a new installation, and you know you can make it work without an SCAP profile....why aren't you just reinstalling to get this going??

Again, have you tried downloading the firmware as suggested? Have you looked in the dmesg logs for anything related to the adapter?? Tried editing the file from the RHEL knowledgebase??

I think you misunderstood what I was saying. I installed it on my laptop so I can use it and play around with it in an environment where it's not critical if I break stuff, since it's my own personal hardware. When the project starts, I will have to work DIRECTLY on the compute cluster where only RedHat is installed and I highly doubt the IT team will install Linux Mint or any other distro on their cluster just to make me happy.

And I didn't say you needed to, did I? I said the system you connect to the cluster WITH doesn't make a difference. Again, you don't *NEED RHEL* to learn Linux...any flavor on your laptop will teach you 99% of the exact same commands, syntax, etc.

That's exactly the reason I need to use RHEL, because if things don't 'just work' there is the option of getting professional help from RedHat support since we are only using packages that are supplied by RedHat and therefore covered by their support and their online tutorials, etc. If I use Mint, Ubuntu or any other 'community's distro, there is no guarantee that anybody will or even can help me.

And how is that support working out for you now, with your current hardware problem?

Things have been suggested; either try them or not. Can't offer more advice when you haven't done/tried anything suggested so far, or posted any more details past "it won't connect". Good luck.

Originally Posted by TB0ne That is changing a text file and rebooting. And if you actually read the WHOLE sentence, it says it's not recommended to USE MD5...not that editing that file is bad.

We're talking about the same portion of the Release Notes, right? This one:

Verification of signatures using the MD5 hash algorithm is disabled in Red Hat Enterprise Linux 7

It is impossible to connect to any Wi-Fi Protected Access (WPA) Enterprise Access Point (AP) that requires MD5 signed certificates. To work around this problem, copy the wpa_supplicant.service file from the /usr/lib/systemd/system/ directory to the /etc/systemd/system/ directory and add the following line to the Service section of the file:

Environment=OPENSSL_ENABLE_MD5_VERIFY=1 

Then run the*systemctl daemon-reload*command as root to reload the service file.

Important: Note that MD5 certificates are highly insecure and Red Hat does not recommend using them. (BZ#1062656)

Correct?

I'm not an expert but that line sounds suspiciously like it enables verification of SSL connections using MD5 hashing somewhere (everywhere?) in the authentification process which nobody in the world should ever do past 200...4?

You said before that you've never used RHEL before...now you're saying you DID use it, and used RHEL 7 on this same hardware and it somehow worked fine? Yet the same RHEL 7 doesn't work now? And since this is a new installation, and you know you can make it work without an SCAP profile....why aren't you just reinstalling to get this going??

As you can see from the original post here, I made that claim on 15th of March 2019. I reinstalled RHEL WITHOUT the SCAP profile yesterday (17th of March 2019) and wireless worked fine. However, I want the SCAP profile. Why would I not take advantage of a security feature (SCAP) and trade it for convenience (wireless)?

Again, have you tried downloading the firmware as suggested? Have you looked in the dmesg logs for anything related to the adapter?? Tried editing the file from the RHEL knowledgebase??

The MD5 thing I didn't try because it sounds like it enables the use of MD5 in some part of SSL which isn't n option. I will try the firmware as soon as I get home. I think the firmware could already be the answer but I can't test it, yet, because my laptop is at home. I'll post as soon as I've tried it.

And I didn't say you needed to, did I? I said the system you connect to the cluster WITH doesn't make a difference. Again, you don't *NEED RHEL* to learn Linux...any flavor on your laptop will teach you 99% of the exact same commands, syntax, etc.

The thing is: You're not allowed to use your personal hardware (i.e. my laptop in question) and go anywhere near the compute cluster with it. The workstations we have to use to connect to the cluster are provided by the IT team, are located in a room you need a chip card to get into and ALSO run RHEL (the workstation flavor, obviously). There is no option to use anything but RHEL if you want to do anything with our cluster (and not get fired) Not sure if all this is necessary but I'm not really in a position to argue with our IT team. I just have to bend over and use what they tell me to...

how is that support working out for you now, with your current hardware problem?

The support is NOT working out for me because I'm having a PRIVATE problem with my PRIVATE hardware right now and they don't give a damn. When I'll be having PROFESSIONAL problems on UNIVERSITY hardware: everything changes...

Things have been suggested; either try them or not. Can't offer more advice when you haven't done/tried anything suggested so far, or posted any more details past "it won't connect". Good luck.

I will try the firmware ASAP but won't try the MD5 thing unless there is documentation somewhere that guarantees that enabling the option will not lead to MD5 being actively used for anything on my PC.


EDIT:
Googling suggests that the option enables the use of MD5 for certificate verification which sounds like a good way to get your box compromised by the first script kid that finds your IP.