| Summary: | Migration of WPA-EAP MSCHAPv2 secrets from NM 0.8 user connections to NM 0.9 doesn't work (20110616 nm09 snapshot) | ||
|---|---|---|---|
| Product: | [Unmaintained] Network Management | Reporter: | Kevin Kofler <kevin.kofler> |
| Component: | Wireless | Assignee: | Lamarque V. Souza <lamarque> |
| Status: | RESOLVED WAITINGFORINFO | ||
| Severity: | major | CC: | collura, lamarque, laurent.rineau |
| Priority: | NOR | ||
| Version: | 0.9 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Kevin Kofler
2011-06-25 22:45:23 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. 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! |