Bug 276485 - Migration of WPA-EAP MSCHAPv2 secrets from NM 0.8 user connections to NM 0.9 doesn't work (20110616 nm09 snapshot)
Summary: Migration of WPA-EAP MSCHAPv2 secrets from NM 0.8 user connections to NM 0.9 ...
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: Network Management
Classification: Unclassified
Component: Wireless (show other bugs)
Version: 0.9
Platform: Fedora RPMs Linux
: NOR major (vote)
Target Milestone: ---
Assignee: Lamarque V. Souza
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-25 22:45 UTC by Kevin Kofler
Modified: 2012-07-17 14:58 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Kofler 2011-06-25 22:45:23 UTC
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.
Comment 1 Lamarque V. Souza 2011-06-26 01:35:31 UTC
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.
Comment 2 Kevin Kofler 2011-06-26 02:20:23 UTC
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.
Comment 3 Lamarque V. Souza 2011-06-26 02:59:53 UTC
(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.
Comment 4 Kevin Kofler 2011-06-26 06:46:14 UTC
One important detail is that only my WPA-EAP (MSCHAPv2) passwords didn't get migrated properly, my WPA-PSK connections' PSKs did.
Comment 5 Lamarque V. Souza 2011-06-26 07:27:01 UTC
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.
Comment 6 Kevin Kofler 2011-06-26 07:29:52 UTC
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.
Comment 7 Lamarque V. Souza 2011-06-26 10:01:20 UTC
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.
Comment 8 Kevin Kofler 2011-06-26 14:52:39 UTC
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.
Comment 9 Lamarque V. Souza 2011-06-26 15:40:15 UTC
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.
Comment 10 Lamarque V. Souza 2011-11-08 15:55:35 UTC
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.
Comment 11 Kevin Kofler 2011-11-08 15:59:51 UTC
Hmmm, I don't have any old NM 0.8 machines left to test the migration on…
Comment 12 Will Stephenson 2011-12-08 11:40:40 UTC
Reassign Network Management bugs to new maintainer.  Have a lot of fun, Lamarque!