RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1305965 - cannot create dynamic wep connection
Summary: cannot create dynamic wep connection
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: control-center
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Matthias Clasen
QA Contact: Desktop QE
URL:
Whiteboard:
: 1049500 1359183 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-09 17:06 UTC by Vladimir Benes
Modified: 2019-07-03 21:03 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-03 21:03:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 767449 0 None None None 2019-07-03 12:05:00 UTC

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.


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