Description of problem:
If knetworkmanager isn't able to associate with a WEP-protected access point
before its internal timeout is exceeded, it forgets its WEP key and asks for
another one. This means that knetworkmanager is destroying user profile data in
the presence of intermittent network faults.
Version-Release number of selected component (if applicable):
Always (assuming the network fault is in effect). A "network fault" that would
prevent access point authentication would include things like
1. invalid (or trivially mis-spelled) WEP key
2. transient device layer problems (see BUG220980).
Steps to Reproduce:
1. Enable knetworkmanager
2. Attempt to connect to a flaky access point
knetworkmanager times out, and deletes its WEP key.
1. knetworkmanager should have a configurable timeout
2. knetworkmanager should offer to re-associate using the saved WEP key
A workaround for the issue is as follows:
1. cancel the WEP key dialog
2. quit knetworkmanager
3. restart knetworkmanager
Do you have kwalletmanager setup and running? all keys are stored in your
encrypted wallet. I have not seen this problem and i have keys stored for
multiple networks and i can switch between them all with out this issue.
I am using kwalletmanager, yes.
As I noted in my workaround, if I cancel the WEP dialog and restart
knetworkmanager, it's able to read the saved passphrase again from kwalletmanager.
The bug here is that, after the association fails, knetworkmanager shows its
dialog *without* the saved WEP key. If you proceed with the dialog, it
erases/overwrites the previous key from kwalletmanager.
knetworkmanager is assuming that you have an incorrect password. and prompting
for a new one. if it was made to just use the old one always you would then
need to go into kwalletmanager if you change your wep id. I believe it is doing
the correct and intended behavior. If you adimitly think it should be changed
please file a bug in KDE's bug system
This is now being tracked on bugs.kde.org as BUG148039. I do think that it's a
bug, but I won't necessarily hold RedHat/Fedora responsible for it.