Bug 982429

I have this problem on a Dell latitude E6410 with intel wireless, currently running Fedora 18 (Lxde spin with extras installed) kernel 3.9.9-201.fc18.x86_64 #1 SMP Fri Jul 5 and NetworkManager version NetworkManager-0.9.8.2-1.fc18.x86_64 polkit-0.107-5.fc18.x86_64, gnome-keyring-3.6.3-1.fc18.x86_64,dbus-1.6.12-1.fc18.x86_64, all of which seem to be involved in a complex tangle of security relationships that I can't understand.
 
NM works perfectly with most wifi connections, eg. WPA/WPA2 personal and with my Three mifi device, also hotel wifi connections, and the campus 'guest' connection. 

But it refuses to store a password for 'Enterprise' wifi systems including our campus enterprise wifi service and eduroam using WPA&WPA2Enterprise + PEAP + CA certificate + MSCHAPv2.

This means that I keep having to type in the password every time I wish to connect to one of those services. If the connection drops for some reason it will not reconnect automatically: I have to run nm-connection-editor or invoke it via "gnome-control-center network" which now launches a much better interface to NetworkManager than used to be available.

It remembers ssids, path name to certificate, user name, and other settings, but will not store the password and it ignores the password specified in /etc/wpa_suppplicant/wpa_supplicant.conf which used to work. 

So every time I want to connect or reconnect I have to go back into the connection editor and type the password then 'save' and it connects. But it doesn't remember the password if I immediately go back back and look at the WiFi-Security tab in the connection editor.

I think this is a relatively new problem: I used to be able to connect to these enterprise wifi services automatically whenever I started up my laptop. I previously used wicd as it's interface (wicd-client -n) is much better than NMs. but that stopped allowing me to store any passwords in Fedora 17, so I switched to NM, which worked tolerably.

I upgraded to F18 mid June 2013 to find out if pm-hibernate had been fixed (It has: always thaws perfectly for me now).

But NM has been very frustrating and wicd doesn't work at all (possibly for related reasons?)

I have the impression this is a problem for many other versions of linux: there seem to be lots of web sites with people complaining about NM passwords in Ubuntu, Arch linux, and others I think.

I have seen all sorts of suggested causes/remedies mentioning dbus, gnome-keyring, polkit and possibly other things. But I have not found anything that allows me to store passwords for Enterprise wifi.

I suspect somebody changed something connected with levels of security and forgot to make sure that it was fully integrated with the rest of the system. I hope nobody has deliberately made it impossible for linux users to store enterprise wifi passwords.

Another clue: if I run nm-connection-editor either directly from the command-line or via gnome-control-center then if I select an enterprise wifi connection to edit, I immediately get a stream of error messages, all saying:

** (nm-connection-editor:5196): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security

I don't get that warning for non-enterprise wifi.

Any suggestions of things to try to help pin this down?

Apologies: I somehow missed part of the bug specification:

   Private key password: ********
   Cancel/Connect
   (Saved password is in the password field)

In my case I always had to type in the password in the connection editor.

However, since my previous comment I have found a solution to my problem which may or may not help the poster: I edited this file where XXXX is the essid

  /etc/sysconfig/network-scripts/ifcfg-XXXX

replacing the line:

  IEEE_8021X_PASSWORD_FLAGS=user

with

  IEEE_8021X_PASSWORD=PASSWORD

There is probably a way to use wpa_passphrase to avoid storing the password in plain text?

Apologies for my mis-reading.

Thanks to comments above.
I finally solved my problem by following steps:
1. comment out following line in /etc/sysconfig/network-scripts/ifcfg-XXXX where XXXX is the essid
IEEE_8021X_PRIVATE_KEY_PASSWORD_FLAGS=user

2. make a file /etc/sysconfig/network-scripts/keys-XXXX with following line where XXXX is the essid
IEEE_8021X_PRIVATE_KEY_PASSWORD=${your password}

3. change /etc/sysconfig/network-scripts/keys-XXXX to permission 600

(In reply to Daniel from comment #3)
> Thanks to comments above.
> I finally solved my problem by following steps:
> 1. comment out following line in /etc/sysconfig/network-scripts/ifcfg-XXXX
> where XXXX is the essid
> IEEE_8021X_PRIVATE_KEY_PASSWORD_FLAGS=user
> 
> 2. make a file /etc/sysconfig/network-scripts/keys-XXXX with following line
> where XXXX is the essid
> IEEE_8021X_PRIVATE_KEY_PASSWORD=${your password}
> 
> 3. change /etc/sysconfig/network-scripts/keys-XXXX to permission 600

Glad to hear that helped. If you don't want your plain text password to be in the keys-XXXX file, you can use this command to generate an encrypted password:

    wpa_passphrase essid password

and paste the long encrypted password it will print out, in place of the actual password. That works for me.

I have now put my instructions online here:
   http://www.cs.bham.ac.uk/~axs/laptop/wpa/#nm-fixed

I assume all this is a temporary stop-gap until someone fixes the security mechanisms that stop nm-connection-editor (or nm-applet?) working sensibly.

If it cannot store the password the user types in, then, instead of 'silently' failing to do so, it should display a message telling the user that the password cannot be saved, and explaining what to do to fix the problem.

There should be an option to disable the message if the password is not intended to be stored.

In my case, because I use nm-connection-editor directly or invoked via the command

   gnome-control-center network

the symptoms of the problem are slightly different -- I don't see a saved password displayed when connection fails. But it looks as if the same underlying design flaw is responsible -- a complex security mechanism that doesn't take account of all patterns of use of Fedora.

I use the LXDE version of Fedora, but don't use the graphical login mechanism, and I invoke graphical mode using 'startx' and the ctwm window manager. I suspect that NetworkManager is designed on the assumption that everyone uses some standard startup/login mechanism, ignoring the intended versatility of linux.

Google shows many complaints about NetworkManager and passwords.

Bug #974811 "NetworkManager dispatchers dbus services misconfiguration" Seems to be closely related to this one.

(In reply to aaronsloman from comment #5)
> Bug #974811 "NetworkManager dispatchers dbus services misconfiguration"
> Seems to be closely related to this one.

Actually it should be related to "asks for wireless password every time" since the dispatcher stuff isn't related to anything wifi.

(In reply to aaronsloman from comment #4)
> I use the LXDE version of Fedora, but don't use the graphical login
> mechanism, and I invoke graphical mode using 'startx' and the ctwm window
> manager. I suspect that NetworkManager is designed on the assumption that
> everyone uses some standard startup/login mechanism, ignoring the intended
> versatility of linux.

nm-connection-editor stores 802.1x and VPN passwords in the GNOME Keyring, which is started by the session manager.  So yes, if you start the GUI with 'startx', then gnome-keyring-daemon isn't going to be running, and no passwords can be saved.  Which would then result in asking you every time.

So if you run "/usr/bin/gnome-keyring-daemon --daemonize --login" as part of your session startup, are passwords saved when you click "Save" in nm-connectino-editor?

Responding to Dan Williams Comment 7

I have never knowingly made any use of the gnome keyring, so I am skating on thin ice. I've tried to find documentation about it that is specific to recent versions of Fedora (currently using 18) and to launching X without gnome, or kde, etc. by running 'startx', controlled by ~/.xinitrc 

I did manage to get NetworkManager working by directly editing

   /etc/sysconfig/network-scripts/ifcfg-XXXX
   /etc/sysconfig/network-scripts/keys-XXXX

For every ESSID XXXX

But directly editing those files should not be necessary. Unfortunately I have not been able to find any clear up to date Fedora specific documentation about Gnome Keyring and how to use it without using gnome.

I had previously tried launching my window manager ctwm at the end of the .xinitrc file using 'dbus-launch --exit-with-session ctwm' suggested in 'man dbus-launch' for other window managers.

But that did not help with nm-connection editor.

Adding '/usr/bin/gnome-keyring-daemon --daemonize --login'
(before starting the window manager in .ctwmrc) made no difference to the behaviour of nm-connection-editor, whether I use it as root or myself. As soon as I specify a secure wifi connection the 'save' button disappears, and warning messages are printed:
  'Invalid setting: wifi-security' 

I've tried searching for information on how to use NetworkManager with startx but the only documentation available seems to be for Arch Users, and it doesn't seem to work on Fedora 18. 

I have just found this and will explore it:
http://unix.stackexchange.com/questions/50622/using-startx-on-fedora-17-a-non-root-user-cannot-join-new-wireless-networks

(In reply to aaronsloman from comment #8)
> Responding to Dan Williams Comment 7

Just noticed a silly typo in my previous message:

> Adding '/usr/bin/gnome-keyring-daemon --daemonize --login'
> (before starting the window manager in .ctwmrc) made no difference to the
> behaviour of nm-connection-editor, whether I use it as root or myself.

That should have been 'in .xinitrc' not 'in .ctwmrc'

Apologies.

+1 for the original issue here, with multiple WPA2 Enterprise / TLS networks. 

The passphrases are present in the keyring, and are correctly populated (starred out) in the connection dialog, but I still have to click 'connect' every time..

+1, I am running gnome-keyring-daemon.

My user account is very old.  I have not yet tried verifying with a clean user account.

(thanks for the workarounds posted).

(In reply to Jon Escombe from comment #10)
> +1 for the original issue here, with multiple WPA2 Enterprise / TLS
> networks. 
> 
> The passphrases are present in the keyring, and are correctly populated
> (starred out) in the connection dialog, but I still have to click 'connect'
> every time..

This may be relevant: On our campus there are two 'enterprise' wifi services, eduroam and the local one. Both work but the former is slower and I find ssh times out more often. But NetworkManager gave me no mechanism for setting a priority.

I have a partial fix: I edit the ONBOOT line in the file
   /etc/sysconfig/network-scripts/ifcfg-eduroam

to
   ONBOOT=no

In the other ifcfg... file I have 'yes'.

This means that when I travel to another university I replace 'no' with 'yes' until I return.

This can also be set in nm-connection-editor in the General tab by enabling or disabling 'Automatically connect to this network when available', but I don't trust that tool: it sometimes makes changes that stop things working.

(In reply to Jon Escombe from comment #10)
> +1 for the original issue here, with multiple WPA2 Enterprise / TLS
> networks. 
> 
> The passphrases are present in the keyring, and are correctly populated
> (starred out) in the connection dialog, but I still have to click 'connect'
> every time..

Confirmed on a new install of Fedora 19.  Echoing earlier comments ,this is *not* an issue auto-connecting to WPA2 Personal or WEP networks.  WPA Enterprise PEAP/MSCHAPv2 retrieves the correct password from the keyring and populates the dialog but requires a click on the Connect button to get it to connect.  The result is the same whether or not "Make available to other users" is checked.

NetworkManager-0.9.8.2-9.git20130709.fc19.x86_64

(In reply to Michael from comment #13)
> ...
> > The passphrases are present in the keyring, and are correctly populated
> > (starred out) in the connection dialog, but I still have to click 'connect'
> > every time..
> 
> Confirmed on a new install of Fedora 19.  Echoing earlier comments ,this is
> *not* an issue auto-connecting to WPA2 Personal or WEP networks.  WPA
> Enterprise PEAP/MSCHAPv2 retrieves the correct password from the keyring and
> populates the dialog but requires a click on the Connect button to get it to
> connect.  The result is the same whether or not "Make available to other
> users" is checked.
> 
> NetworkManager-0.9.8.2-9.git20130709.fc19.x86_64

On a dell latitude E6410 I am using Fedora 18 with 
NetworkManager-0.9.8.2-1.fc18.x86_64

I found that in order to get everything to work as expected with WPA Enterprise PEAP/MSCHAPv2 I had to do some hand editing of files in /etc/sysconfig/network-scripts.

In particular if your ESSID is XXX see if you have files

    keys-XXX

containing
    IEEE_8021X_PASSWORD=<your password>

(it sounds as if that's there because you don't have to type in the password. It should be readable only by root)

and the file
    ifcfg-XXX

containing, among other things:
 
    ONBOOT=yes

My guess, on the basis of similar experience in the past, is that you have 'no' instead of 'yes' because of some obscure bug in the files for setting up connections.

If so try editing to 'yes'.

Otherwise try launching nm-connection-editor in a terminal window and see if you get any error or warning messages.

In Fedora 18 I can also run this command to launch a network connection panel

     gnome-control-center network

It also seems to be available in F19, but I don't have wifi to test on that. You can also try that and see if it generates any error or warning messages.

(I had to do 'yum install control-center' to get it.)

I still have this problem on Fedora 20 and now the workaround above (putting the password in clear text in /etc/sysconfig/network-scripts/ifcfg-XXX file) isn't working reliably.

It seems to sometimes pop up the gnome-shell dialog (with the password prefilled) and sometimes not.  Perhaps related to which access point I talk too?

Everything still works fine for home connections, just my "enterpise" ones that fail.

This is NetworkManager-1:0.9.9.0-18.git20131003.fc20

(In reply to Colin Macdonald from comment #15)
> I still have this problem on Fedora 20 and now the workaround above (putting
> the password in clear text in /etc/sysconfig/network-scripts/ifcfg-XXX file)
> isn't working reliably.

I found at some stage that I had to have two files. One root-readable only file:

   keys-XXXX

containing only one line specifying the password in this format:

   IEEE_8021X_PASSWORD=MYPASSWORD

and the other file, namely:

   ifcfg-XXXX

no longer containing the wifi password. The lines I have (e.g. for access to our campus enterprise wifi) in that file are now:

   ESSID="XXXXWIFI"
   MODE=Managed
   KEY_MGMT=WPA-EAP
   TYPE=Wireless
   IEEE_8021X_EAP_METHODS=PEAP
   IEEE_8021X_IDENTITY=USERNAME
   IEEE_8021X_CA_CERT=/etc/cert/uob_root_linux.pem
   BOOTPROTO=dhcp
   DEFROUTE=yes
   IPV4_FAILURE_FATAL=yes
   IPV6INIT=no
   NAME=XXXXWIFI
   UUID=(LongUUID inserted by NetworkManager)
   ONBOOT=yes
   HWADDR=AA:BB:CC:DD:EE:FF
   IEEE_8021X_INNER_AUTH_METHODS=MSCHAPV2
   PEERDNS=yes
   PEERROUTES=yes

(With my wireless MAC address for HWADDR.)

For eduroam I have to have USERNAME@..... using the campus address.
For the local enterprise wifi the USERNAME suffices.

> It seems to sometimes pop up the gnome-shell dialog (with the password
> prefilled) and sometimes not.  Perhaps related to which access point I talk

> Everything still works fine for home connections, just my "enterpise" ones
> that fail.

I think those were the symptoms I had at one stage.

> This is NetworkManager-1:0.9.9.0-18.git20131003.fc20

In my case, on Fedora 18:

    NetworkManager-0.9.8.2-1.fc18.x86_64

It may be worth splitting your configuration files as above.

> It may be worth splitting your configuration files as above.

Yes, eventually I was able to get this to work, but I needed to ensure first that /etc/sysconfig/network-scripts/keys-XXXX had the correct SELinux context

    $ sudo restorecon /etc/sysconfig/network-scripts/keys-XXXX

And, I think what had hindered me initially -- after comparing my ifcfg- script with that of aaronsloman above, mine had: 

    IEEE_8021X_PASSWORD_FLAGS=user
    SECURITYMODE=open

Commenting  out IEEE_8021X_PASSWORD_FLAGS seemed to be what got the WPA-enterprise SSID connecting without having to click through the password prompt for me.  I commented out SECURITYMODE=open as well, not sure why that was left in there.

(In reply to Michael from comment #17)
> > It may be worth splitting your configuration files as above.
> 
> Yes, eventually I was able to get this to work, but I needed to ensure first
> that /etc/sysconfig/network-scripts/keys-XXXX had the correct SELinux context
> 
>     $ sudo restorecon /etc/sysconfig/network-scripts/keys-XXXX

Thanks for that tip. I turned off SELinux because it caused me too many problems that I did not know how to resolve. So I did not discover the need for that step.

> And, I think what had hindered me initially -- after comparing my ifcfg-
> script with that of aaronsloman above, mine had: 
> 
>     IEEE_8021X_PASSWORD_FLAGS=user

At one stage that had been inserted in my ifcfg script by NM, and had to be removed. I think that was an earlier version of NM.

>     SECURITYMODE=open

The only time I remember seeing that was when I used NM to connect to a domestic wifi router (from VirginMedia) in a friend's house. It was using the default WPA setting. I had to edit the automatically generated ifcfg file to remove that line.
 
> Commenting  out IEEE_8021X_PASSWORD_FLAGS seemed to be what got the
> WPA-enterprise SSID connecting without having to click through the password
> prompt for me.  I commented out SECURITYMODE=open as well, not sure why that
> was left in there.

NM seems to be very complex, somewhat buggy, and very useful when it works!

Thanks, I got it working again and keys-XXX works again.

Anyway, there is still an actual bug here: shouldn't have to workaround by hacking on ifcfg-XXX and keys-XXX files.  Is there an upstream bug for this? 

(FWIW, I think the SELinux things is a separate issue, the main bug here is one cannot setup these enterprise networks )

(In reply to Colin Macdonald from comment #19)
> Anyway, there is still an actual bug here: shouldn't have to workaround by
> hacking on ifcfg-XXX and keys-XXX files.  Is there an upstream bug for this? 

Oh, certainly there's a bug here. The NM setup GUI ought to be handling all of this.  Seems like we've at least established a reliable workaround though.
 
> (FWIW, I think the SELinux things is a separate issue, the main bug here is
> one cannot setup these enterprise networks )

The SELinux bit isn't part of the bug - it's part of the workaround. In my case, keys-XXXX was *not* created by NM. I had to create it myself and therefore set the correct context on it in addition to making it root 600.

So to restate the bug as experienced since we've gone off track with the workaround: 

When saving credentials for a WPA-Enterprise SSID, NM stores the credentials and successfully retrieves them populating the password entry dialog, but will not auto-connect without manually clicking through the populated password dialog.

Perhaps this is the upstream bug:

https://bugzilla.gnome.org/show_bug.cgi?id=703612

I've requested that re-opened and linked it here.

Occurs on Fedora 20 with UofT's network. (University of Toronto, WPA2 Enterprise) on a fresh Fedora 20 install. 

So long as the connection is strong, I only have to click on 'connect' and I'm good.
But if the connection is weak, then the password prompt keeps coming up.

Mac book air 2011
Security: WPA & WPA2 Enteprise 
Authen: Protected EAP (PEAP)
Inner: MSCHAPv2

Work around above by aaronsloman works for the time being.

Occurs on Fedora 20 installation too.(Truman state University). I think wifi applet run in a loop before I log on since I can see wifi applet flashing. After I logon I need to hit enter even though settings says connect automatically.

Lenovo T510
Security:WPA2 Enterprise
Authen: Protected EAP(PEAP)
Inner:MSCHAPV2

Occurs on Fedora 20 installation too.(Truman state University). I think wifi applet run in a loop before I log on since I can see wifi applet flashing. After I logon I need to hit enter even though settings says connect automatically.

Lenovo T510
Security:WPA2 Enterprise
Authen: Protected EAP(PEAP)
Inner:MSCHAPV2

Occurs on Fedora 20 with New York University network. Prompted for confirmation to connect every time when turning on or waking up the laptop.

Lenovo T431s
WPA2 Enterprise
PEAP
MSCHAPv2

For Fedora 20 users still having problems. It may be worth noting the suggestions in comment 16 (fix found in Fedora 18) and discussion up to comment 22, indicating that the fix also works for Fedora 20. (The problem seems to be a NetworkManager bug).

Because the fix had to be modified at one stage I'll summarise the current fix, as I understand it (used by me on F18, and by others on F20).

If using WPA2 Enterprise wifi, via access point with ESSID XXXX, create or edit two files in directory

    /etc/sysconfig/network-scripts

One file, root-readable only :

   keys-XXXX

The other file:

   ifcfg-XXXX

The first file, keys-XXXX, should contain only one line specifying your password for that network, in this format:

   IEEE_8021X_PASSWORD=MYPASSWORD

(NOTE:
For a while I was able to use the encrypted version of MYPASSWORD generated
by wpa_passphrase, but for some reason that password stopped working and the password had to be in plain text. I don't know if the encrypted version would work on F20)

The second file ifcfg-XXXX should contain this with asterisked portions
(e.g. *XXXX*) changed:

   ESSID="*XXXX*"
   MODE=Managed
   KEY_MGMT=WPA-EAP
   TYPE=Wireless
   IEEE_8021X_EAP_METHODS=PEAP

   IEEE_8021X_IDENTITY=*USERNAME*

   IEEE_8021X_CA_CERT=*PATH TO linux.pem FILE*
   BOOTPROTO=dhcp
   DEFROUTE=yes
   IPV4_FAILURE_FATAL=yes
   IPV6INIT=no

   NAME=*XXXX*

   UUID=*UUID GENERATED BY SYSTEM*

   ONBOOT=yes

   HWADDR=*AA:BB:CC:DD:EE:FF*

   IEEE_8021X_INNER_AUTH_METHODS=MSCHAPV2
   PEERDNS=yes
   PEERROUTES=yes

   USERS=*your login name on the machine to restrict access to you*

(With your wireless MAC address for HWADDR.)

For eduroam, in the IDENTITY line, I have to have USERNAME@..... using the campus address.

For the local enterprise wifi the USERNAME suffices.

NOTES:

In comment #17 it is suggested that you also need to execute a 'restorecon' command, though I don't need it on my machine, as I have turned off SELinux:  I.e. ensure that /etc/sysconfig/network-scripts/keys-XXXX has the correct SELinux context

    $ sudo restorecon /etc/sysconfig/network-scripts/keys-XXXX
 
First try without that, and connection does not work as expected, try that command. See comments #19 and #20

The CA_CERT requirement is discussed in
    https://bugzilla.gnome.org/show_bug.cgi?id=702608

I've re-opened the bugzilla defect.

They're requesting logs and information:

> This looks like an issue with a keyring. Do you have a keyring installed?
> Would you grab NetworkManager logs? (I think they are in /var/log/daemon.log or
> in systemd journal: journalctl)

I have now updated my laptop (DEC Latitude E6410) from Fedora 18 to F20, with 
NetworkManager-0.9.9.0-38.git20131003.fc20.x86_64

There has been some improvement. I now find that if I fill in the fields properly in the connection editor for ESSID "FOO" using WPA&WPA2Enterprise + PEAP + CA certificate + MSCHAPv2, then it creates the two files in
  /etc/sysconfig/network-scripts
that I previously had to create or edit by hand

Sorry: comment #28 accidentally submitted in unfinished form.

I have now updated my laptop (DEC Latitude E6410) from Fedora 18 to F20, with 
NetworkManager-0.9.9.0-38.git20131003.fc20.x86_64

There has been some improvement. I now find that if I fill in the fields properly in the connection editor for ESSID "FOO" using WPA&WPA2Enterprise + PEAP + CA certificate + MSCHAPv2, then it creates the two files in
  /etc/sysconfig/network-scripts
that I previously had to create or edit by hand, e.g. 
    ifcfg-FOO
containing most of the connection specification and
    keys-FOO
containing the password in the format

    IEEE_8021X_PASSWORD=<password>

with the password still unencrypted unfortunately.

As a result the password is now remembered across sessions without the user having to edit the files by hand.

It is possible to specify for this type of connection whether it should be automatically used if the ESSID is available or not, producing a line with either "ONBOOT=yes" or "ONBOOT=no" in the ifcfig-FOO file.

This option is still available in the new connection editing facility but it is presented differently for enterprise wifi connections and others, which can be confusing at first.

This is important for sites where two networks are available (e.g. eduroam and a campus wifi network). If both are set to 'ONBOOT=yes" then as signal strenths vary the network manager can switch between the connections, which can be very disruptive. NetworkManager should never automatically change to another ESSID which has not been explicitly selected without asking the user.

At present, to avoid this behaviour I have to set ONBOOT=no for eduroam, with the consequence that when visiting another campus it will not connect to an available eduroam network automatically, whenever starting up. That can be a nuisance, although a minor one. 

However overall it seems (after two days testing F20) that things have got better, though it is annoying that there is a command nm-connection-editor but not something like nm-connection-select (with its own documentation). Instead you have to discover that "gnome-control-center network" performs that function, which is rather obscure. (I discovered it only by accident.)

Is the suggestion to delete all connections exhibiting this problem and re-enter them on F20?

This bug still exists for me on F20, though this was an upgrade from F19 with settings for networks mostly unchanged.

(In reply to Kevin R. Page from comment #30)
> Is the suggestion to delete all connections exhibiting this problem and
> re-enter them on F20?
> 
> This bug still exists for me on F20, though this was an upgrade from F19
> with settings for networks mostly unchanged.

In my case, when I upgrade I keep the old /boot /swap /home /usr/local partitions, and a few others, but start a new root partition. This enables me to reboot to the previous version if something goes badly wrong with the new installation. (It needs a bit of care during installation!).

So in effect I did delete all my old connections, though all the information remains in /f18/etc/sysconfig/network-scripts for comparison with the new f20 versions in /. One change I don't like is that the wireless interface is no longer called wlan0 but has a new unmemorable gobbledygook name shown by 'ifconfig': wlp2s0 (google shows quite a lot of discussion about problems with interface name changes). I don't know if that change occurred between F19 and F20, or between F18 and F19.

You could try backing up the contents of the network-scripts directory, then either deleting the files for your wireless connections or using the connection editor (e.g. nm-connection-editor) to delete them, then re-connect. Once or twice I have found that doing that fixes a wifi access problem. But I am no expert and my experiments are mostly blind.

To further debug the password issue, could you run 'seahorse' and browse around in your keyrings for passwords that are stored there, to make sure it's not getting saved in the keyring?

Also, GNOME desktop, KDE, LXDE, XFCE, or something else?

(In reply to Dan Williams from comment #32)
> To further debug the password issue, could you run 'seahorse' and browse
> around in your keyrings for passwords that are stored there, to make sure
> it's not getting saved in the keyring?
> 
> Also, GNOME desktop, KDE, LXDE, XFCE, or something else?

First of all, my problem had been solved as described in comment #3.
Here is my current system:
$ cat /proc/version 
Linux version 3.14.8-200.fc20.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #1 SMP Mon Jun 16 21:57:53 UTC 2014

Also, I am using MATE desktop.

Because I do not know how to use 'seahorse', I will attach my screen-shot of seahorse.

Created attachment 911398 [details]
seahorse: login tab

Created attachment 911399 [details]
seahorse default tab

Created attachment 911400 [details]
seahorse gnome2 key storage tab

Created attachment 911401 [details]
seahorse: user key storage tab

Created attachment 911402 [details]
seahorse: system trust tab

Created attachment 911403 [details]
seahorse: default trust tab

(In reply to Daniel from comment #34)
> Created attachment 911398 [details]
> seahorse: login tab

I had also never used seahorse, or heard of it, but found it on my system (running 3.14.8-200.fc20.x86_64 on Fedora+XFCE using ctwm window manager). So I've tried running seahorse and it gave me similar displays to yours.

Did you try clicking on "+" on the first menu?  It gave me a sub-menu, whose second item was labelled: "Password keyring: Used to store application and network passwords"

When I clicked on 'continue' it asked me to give a name for a new keyring.

Since I have a working system I decided to abort in case I screwed it up.
If you don't yet have networking working then it may be worth exploring to see
what you can gain using a keyring.

It may be more secure than my method, which used nm-connection editor to create entries in /etc/sysconfig/network-scripts as in Comment #29

In F20 it produces files with similar contents to the ones I had in F18. However, the UUID entries are different.

So if you preserved contents of the network-scripts directory when upgrading from F19 to F20 it may be worth removing or renaming your two files for the problematic connection (e.g. FOOO):
    ifcfg-FOOO
    keys-FOOO

PS
Thanks for drawing my attention to MATE. I had never heard of it, but now find it has things I need, including the atril document viewer, since evince went downhill.... Perhaps it has something better than nm-connection-editor?

(In reply to aaronsloman from comment #40)
> (In reply to Daniel from comment #34)
> > Created attachment 911398 [details]
> > seahorse: login tab
> 
> I had also never used seahorse, or heard of it, but found it on my system
> (running 3.14.8-200.fc20.x86_64 on Fedora+XFCE using ctwm window manager).
> So I've tried running seahorse and it gave me similar displays to yours.
> 
> Did you try clicking on "+" on the first menu?  It gave me a sub-menu, whose
> second item was labelled: "Password keyring: Used to store application and
> network passwords"
> 
> When I clicked on 'continue' it asked me to give a name for a new keyring.
> 
> Since I have a working system I decided to abort in case I screwed it up.
> If you don't yet have networking working then it may be worth exploring to
> see
> what you can gain using a keyring.
> 
> It may be more secure than my method, which used nm-connection editor to
> create entries in /etc/sysconfig/network-scripts as in Comment #29
> 
> In F20 it produces files with similar contents to the ones I had in F18.
> However, the UUID entries are different.
> 
> So if you preserved contents of the network-scripts directory when upgrading
> from F19 to F20 it may be worth removing or renaming your two files for the
> problematic connection (e.g. FOOO):
>     ifcfg-FOOO
>     keys-FOOO
> 
> PS
> Thanks for drawing my attention to MATE. I had never heard of it, but now
> find it has things I need, including the atril document viewer, since evince
> went downhill.... Perhaps it has something better than nm-connection-editor?

Thank you very much for your reply.
I deleted my ifcfg-F000 and keys-F000 files and tried to add a new wifi connection in nm-connection-editor.
Now I can comfirm my wifi password in "default" tab of seahorse, and I can connect to my wifi network without any problems(even after a reboot).
Should I close this bug?

I have just installed Fedora 20 with KDE and network manager can't remember password for ALL connections, not just enterprise connections. 
I also have KWallet disabled as it doesn't work (but thats another bug).

Is this the same bug or should it be a new bug (as all the discussion in this thread has been about enterprise connections and interraction with Gnome Keyring

(In reply to JohnL53 from comment #42)
> ....
> Is this the same bug or should it be a new bug (as all the discussion in
> this thread has been about enterprise connections and interraction with
> Gnome Keyring

I wonder if it is a kde problem. I have never tried using that.

If it has a different cause the solutions that work for this bug may still help.

I have fedora 20 +XFCE running on a laptop with NetworkManager. I don't use kde, gnome or the xfce window manager (ctwm is my window manager).

But nm-connection-editor and gnome network utilities (invoked from the shell or ctwm mouse menu by 'gnome-control-center network') both seem to work for me.

In all cases I end up with files in /etc/sysconfig/network-scripts of the form ifcfg-ESSID, and, in the case of connections requiring a password, an additional file keys-ESSID, as described in Comment#26

You could try manually creating the files as described in that comment.
The format for non-enterprise wifi connections is different. E.g. for connecting to my home router the keys-ESSID file has

     WPA_PSK='unencrypted password'

and the ifcfg-ESSID file has

   ESSID="ESSID"
   MODE=Managed
   KEY_MGMT=WPA-PSK
   TYPE=Wireless
   BOOTPROTO=none
   DEFROUTE=yes
   IPV4_FAILURE_FATAL=yes
   IPV6INIT=yes
   IPV6_AUTOCONF=yes
   IPV6_DEFROUTE=yes
   IPV6_FAILURE_FATAL=no
   NAME=ESSID
   UUID=<UUID provided by system>
   ONBOOT=yes
   IPADDR0=192.168.0.xx
   PREFIX0=24
   GATEWAY0=192.168.0.yy
   DNS1=192.168.0.zz
   DNS2=<service provider dns address>
   DOMAIN=<service provider domain>
   HWADDR=[MAC address for wifi device]
   IPV6_PEERDNS=yes
   IPV6_PEERROUTES=yes

(The only thing that could be a problem is the UUID, unless you know how to get that for your wireless device. I have always found it inserted automatically in the ifcfg-xxx files.)

I also found at one point that I had to create a directory /run/user/nnn
where nnn is my user number owned by me, with mode:  drwx------ 

I don't know why that was not created automatically -- perhaps because I don't use one of the standard desktop systems. I recently replaced my laptop hard drive with a new one and had to recreate that directory again after starting up the first time. It's a tmpfs directory, but I don't seem to have to recreate it after each reboot.

Perhaps you need such a directory if it doesn't already exist.

You could try seahorse, which seems to be able to set up an initial configuration -- I did not learn about it until after I had got things working, and I did not want to risk using it. Perhaps kde provides an alternative.

> I also have KWallet disabled as it doesn't work (but thats another bug).

It is possible that disabling KWallet prevents creation of some of the files/directories needed. If you can't even connect to a free wifi system that doesn't require a password, then perhaps something just isn't turning on your wireless system -- a different bug.

In case it isn't obvious: my example file uses fixed addresses. 

For dhcp insert:

   BOOTPROTO=dhcp

and delete these lines:

   BOOTPROTO=none
   IPADDR0=192.168.0.xx
   PREFIX0=24
   GATEWAY0=192.168.0.yy
   DNS1=192.168.0.zz
   DNS2=<service provider dns address>
   DOMAIN=<service provider domain>

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.