Version: 0.9 (using KDE 4.6.3) OS: Linux In Fedora, we are currently testing kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15, a build from the nm09 branch. I had some trouble with migration of WPA-EAP MSCHAPv2 secrets from previous 0.8-based versions. (I previously used kde-plasma-networkmanagement-0.9-0.47.20110323.fc15 and kde-plasma-networkmanagement-0.9-0.47.20110323.fc15.1, which use the 0.8-style settings through that Fedora-specific compatibility API, and kde-plasma-networkmanagement-0.9-0.40.20110323.fc14 and older builds, which used NM 0.8, before that. I must have set up those connections with some Fedora 14 or older build.) 1. Migration should create a IEEE_8021X_PASSWORD_FLAGS=user entry in the ifcfg-rh config file (probably a flag to set through the NM API), it fails to do that. (In particular, this means the connection fails to load entirely in NetworkManager, which requires either a (nonempty) IEEE_8021X_PASSWORD entry or a IEEE_8021X_PASSWORD_FLAGS=user entry, and your configuration is completely lost unless you can deal with hand-editing config files.) 2. Migration should store the password in KWallet, it fails to do that. I have to enter it there manually. (In particular, this means the stored password is lost, because the original connections got deleted. If you don't remember it, you're screwed.) Reproducible: Always Steps to Reproduce: 1. Set up user connections of WPA-EAP type with MSCHAPv2 authentication with (any version of) kde-plasma-networkmanagement trunk. (I used 20110323 and earlier snapshots, but even current trunk should reproduce this as long as the connection is a user connection.) Have them store the password in KWallet (which is the default). 2. Upgrade to the nm09 branch of kde-plasma-networkmanagement. Actual Results: WPA-EAP MSCHAPv2 passwords are lost, and their complete absence in the config file (they are neither written out nor flagged as per-user) makes NM ignore the connection entirely until fixed. Expected Results: WPA-EAP MSCHAPv2 passwords are migrated correctly. This bug causes the password to be lost entirely, and the rest of the connection to be lost unless you know (or can figure out) how to edit ifcfg files manually.
This is strange, branch nm09 and master use the same location to store secrets. The importer only imports settings, not secrets, because secrets are already at the right place. We also does not delete secrets during importing, only settings files.
Well, when I just added IEEE_8021X_PASSWORD_FLAGS=user to the config file, I was told there was "no agent for this secret" or something like that (I don't remember the exact text of the message) and the password came up blank. I had to reenter it and save it to get it added into the wallet.
(In reply to comment #2) > Well, when I just added IEEE_8021X_PASSWORD_FLAGS=user to the config file, I > was told there was "no agent for this secret" or something like that (I don't > remember the exact text of the message) and the password came up blank. I had > to reenter it and save it to get it added into the wallet. The fact that the password is not shown in the edit dialog does not necessarily mean it is not in kwallet. I will have to upgrade my NetworkManager to test this bug.
One important detail is that only my WPA-EAP (MSCHAPv2) passwords didn't get migrated properly, my WPA-PSK connections' PSKs did.
Well, I cannot test this properly because the add connection feature in Plasma NM relies on NM calling the secret agent to save the secrets and it seems NM >= 0.8.9997 calls the agent to save the old secrets instead of the new one during connection updates. Since we do not touch the secrets during settings importing it should have worked for all connections unless WPA-EAP connections has a new setting I am not aware of that makes NM refuses the connection. Something similar has already happened with vpnc and openvpn connections. I have downgraded the minimum NM required by Plasma NM to 0.8.999, this one seems to be the most reliable NM-0.9 version so far.
Well, WPA-EAP has a setting which ifcfg-rh writes out as "IEEE_8021X_PASSWORD_FLAGS=user". Either that or an IEEE_8021X_PASSWORD entry is expected, or NM considers the configuration invalid.
Either?! I think you meant both must be set, there is no sense in setting a secret flag without the secret. Anyway, we set the equivalent to those two options.
If IEEE_8021X_PASSWORD_FLAGS=user is set, the IEEE_8021X_PASSWORD is not stored in the config file, but as a secret. If IEEE_8021X_PASSWORD_FLAGS=user is not set, NM expects the IEEE_8021X_PASSWORD to be set inside the config file.
Ok, now I get it. I thought about how NM's clients should act and I forgot ifcfg-rh is used by NM daemon, not clients.
Is this still happening? Please test with NM >= 0.9.0 and Plasma NM 0.8.95. The bug in NM that prevented it from saving secrets was fixed in 0.9.0 and Plasma NM's secret management code has changed since June.
Hmmm, I don't have any old NM 0.8 machines left to test the migration on…
Reassign Network Management bugs to new maintainer. Have a lot of fun, Lamarque!