Bug 1305965

Summary: cannot create dynamic wep connection
Product: Red Hat Enterprise Linux 7 Reporter: Vladimir Benes <vbenes>
Component: control-centerAssignee: Matthias Clasen <mclasen>
Status: CLOSED CURRENTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: aloughla, atragler, bgalvani, fgiudici, lmiksik, lrintel, mclasen, pgeorgie, rkhan, thaller, vbenes, vrutkovs
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-03 21:03:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Vladimir Benes 2016-02-09 17:06:10 UTC
Description of problem:
every time I create wep enterprise profile it switches back to key management.

I use something like this:
        | Tab      | Field                | Value                          |
        | Security | Security             | Dynamic WEP (802.1x)           |
        | Security | Authentication       | Tunneled TLS                   |
        | Security | Anonymous identity   | Bill Smith                     |
        | Security | CA certificate       | /tmp/certs/eaptest_ca_cert.pem |
        | Security | Inner authentication | MSCHAPv2                       |
        | Security | Username             | Bill Smith                     |
        | Security | Password             | testing123                     |

but the connection looks like:
802-11-wireless-security.key-mgmt:      none
802-11-wireless-security.wep-tx-keyidx: 0
802-11-wireless-security.auth-alg:      --
802-11-wireless-security.proto:         
802-11-wireless-security.pairwise:      
802-11-wireless-security.group:         
802-11-wireless-security.leap-username: --

but it should look like (from working NM test):
802-11-wireless-security.key-mgmt:      ieee8021x
802-1x.eap:                             ttls
802-1x.phase2-auth:                     mschapv2
802-1x.identity:                        Bill Smith
802-1x.password:                        testing123
802-1x.ca-cert:                         file:///tmp/certs/eaptest_ca_cert.pem

Version-Release number of selected component (if applicable):
NetworkManager-1.0.6-27.el7.x86_64
control-center-3.14.5-8.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.create new connection as shown above (I can provide machine with available AP)
2.connect

Actual results:
impossible, connection when edited again shows WEP Key type again

Expected results:
connect possible, profile correctly set and remembered

Additional info:
AFAIK this affects TLS and TTLS wep enterprise types, I have no other types to check.

Comment 5 Vladimir Benes 2016-03-02 13:18:52 UTC
*** Bug 1049500 has been marked as a duplicate of this bug. ***

Comment 12 Bastien Nocera 2016-06-02 16:13:52 UTC
I've looked at this bug into more details, getting information from dcbw as well.

1) Can you rename the bug to "Dynamic WEP"? I looked for "wep enterprise" and could not find anything related to that. dcbw explained that it was "Dynamic WEP", for which I was able to find information.

2) The bug is marked as a regression. From which product/version is that a regression? How did it work in that version?

3) 
> every time I create wep enterprise profile it switches back to key management.

- How do you create the profile?
- Can you explain the exact steps in the UI?
- Do you click on the gear button in the list of APs and modify the settings by hand? (in which case, I don't need access to the AP to verify that the values are saved correctly)

Comment 14 Bastien Nocera 2016-06-06 16:52:00 UTC
Can you answer the questions in comment 12 please?

Comment 16 Bastien Nocera 2016-06-09 13:11:10 UTC
I'll reassign to NetworkManager for now, because it doesn't work in nm-connection-editor either, which gnome-control-center's Network Security pages are based on.

Comment 21 Vladimir Benes 2016-07-25 11:52:28 UTC
*** Bug 1359183 has been marked as a duplicate of this bug. ***

Comment 23 Francesco Giudici 2016-08-05 17:06:29 UTC
I have been able to reproduce the issue in this way:
1) Choose a WEP or WPA-PSK protected WiFi network from gnome applet
2) When prompted for the key just cancel
3) Then change the connection in gnome-control-center as per Vlad settings (change it to Dynamic WEP (802.1X))

If you now check the connection (nmcli c s) you will see that the settings have not been changed.

If you try to perform point 3) with nm-connection-editor, it works.

If you open it after the change with gnome-control-center, you will se all the option correctly but any change in any option (e.g., the identity field) will not be saved.

So, I will reassign the bug to gnome-control-center for further investigation.

Comment 25 Bastien Nocera 2016-08-29 14:45:23 UTC
I cannot find a version of RHEL where dynamic WEP works properly. I also could not setup an Access Point locally to debug this problem.

Given that dynamic WEP is a very niche setup, I'll punt this to RHEL 7.4, which would hopefully come with an updated control-center package, and focus on fixing the problem upstream.

Comment 27 Bastien Nocera 2016-09-14 10:54:24 UTC
(In reply to Bastien Nocera from comment #25)
> I cannot find a version of RHEL where dynamic WEP works properly. I also
> could not setup an Access Point locally to debug this problem.

Removed the regression keyword.

FWIW, upstream bug was updated:
Retitling. I discussed "Dynamic WEP" support with Cisco and it is not supported by the latest APs or other network hardware they ship.

https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_01010100.html#ID957

"Dynamic WEP encryption method is not supported. The last release to support this method was Release 7.0 "
Last 7.0 releases were in 2011.

Comment 30 Pavlin Georgiev 2019-07-03 12:11:20 UTC
This type of authentication works under RHEL 8.1.

See: http://beaker-archive.host.prod.eng.bos.redhat.com/beaker-logs/2019/06/36360/3636057/7061809/95523427/437461827/report_control-center-wireless-display_Test016_gcc_wifi_wep_ttls.html

It will be checked under RHEL 7.7 as well.

Comment 31 Pavlin Georgiev 2019-07-03 21:02:16 UTC
TEST SETUP
Distro: RHEL 7.6 Released
Component version: control-center-3.28.1-4.el7

TEST PROCEDURE
1. Install distro RHEL 7.6 on a physical machine in our wireless lab.
2. Run the following automated test:

  Scenario: Wi-Fi-sec - configure and connect WEP-TTLS profile
    * Start gnome-control-center via command in session ... passed in 10.230s
    * Open section "Wi-Fi" in settings ... passed in 4.691s
    * Connect to "qe-wep-enterprise" WiFi AP using "Cancel" password ... passed in 12.072s
    * Open details for "qe-wep-enterprise" WiFi connection ... passed in 22.942s
    * Set the following parameters for "qe-wep-enterprise" profile ... passed in 45.653s
      | Tab      | Field                | Value                          |
      | Security | Security             | Dynamic WEP (802.1x)           |
      | Security | Authentication       | Tunneled TLS                   |
      | Security | Anonymous identity   | Bill Smith                     |
      | Security | CA certificate       | /tmp/certs/eaptest_ca_cert.pem |
      | Security | Inner authentication | MSCHAPv2                       |
      | Security | Username             | Bill Smith                     |
      | Security | Password             | testing123                     |
    * Save profile changes ... passed in 6.463s
    * Connect to "qe-wep-enterprise" WiFi AP with no password set ... passed in 5.549s
    Then "qe-wep-enterprise" is visible with command "nmcli --terse -f DEVICE,TYPE,STATE,CONNECTION device | grep -w wifi | grep -w connected | awk -F: '{print $4}'" in "30" seconds ... passed in 0.305s
    Then "qe-wep-enterprise" is visible with command "iw dev wlan0 link | grep -w SSID | awk -F': ' '{print $2}'" in "10" seconds ... passed in 0.190s
    Then Wi-Fi connection status is "Connected" ... passed in 3.065s

  1 feature passed, 0 failed, 20 skipped
  1 scenario passed, 0 failed, 170 skipped
  10 steps passed, 0 failed, 1181 skipped, 0 undefined
  Took 1m51.160s

  + RC=0
  + logger -t ./runtest.sh 'Running test gcc_wifi_wep_ttls...end'
  + '[' 0 -eq 0 ']'
  + RESULT=PASS


RESULT
Upgrading component: control-center
    from: 3.14.5-8.el7
      to: 3.28.1-4.el7
has fixed the bug.