Bug 682972 - kde-plasma-networkmanagement: WiFi authentication regression
Summary: kde-plasma-networkmanagement: WiFi authentication regression
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-plasma-networkmanagement
Version: 14
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 683603 684022 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-08 07:14 UTC by Andrei Gaponenko
Modified: 2011-04-04 01:30 UTC (History)
11 users (show)

Fixed In Version: kde-plasma-networkmanagement-0.9-0.39.20110314.fc13
Clone Of:
Environment:
Last Closed: 2011-03-23 22:55:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
The yum transaction that broke WiFi (3.14 KB, text/plain)
2011-03-08 07:14 UTC, Andrei Gaponenko
no flags Details
grep NetworkManager /var/log/messages | tail -n 50 (6.42 KB, text/plain)
2011-03-08 18:56 UTC, Germano Massullo
no flags Details
grep NetworkManager /var/log/messages | tail -n 50 of Thinkpad R500 (5.48 KB, text/plain)
2011-03-08 21:13 UTC, Germano Massullo
no flags Details


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 243792 0 None None None Never
KDE Software Compilation 247044 0 None None None Never

Description Andrei Gaponenko 2011-03-08 07:14:29 UTC
Created attachment 482846 [details]
The yum transaction that broke WiFi

Hi,

Today's "yum update" broke WiFi connectivity on a Fedora 14 KDE
laptop.  The network is WEP encrypted.  A window titled

"Secrets for <my-network-ssid> - KDE Daemon"

pops up, with the connection password pre-filled.  The NetworkManager
icon in the tray stays in the "Waiting for authorization" state
even after the "OK" button in the popup window is clicked, and a
connection is never established.

Before the today's package update the connection to this network
established automatically without any popups.

The situation is exacerbated by the fact that

    "yum history undo last"

does not work (see bug #652767).  If there is no other quick solution,
can please the problematic upgrade be "undone" at the repository level
by putting out rpms with the old code but new higher numbers?

Attached is the output of "yum history info".

Thank you,
Andrei

Comment 1 Kevin Kofler 2011-03-08 09:37:16 UTC
> can please the problematic upgrade be "undone" at the repository level
> by putting out rpms with the old code but new higher numbers?

No, sorry. The new snapshot fixes many bugs other people have encountered, reverting would regress things for them.

Comment 2 Kevin Kofler 2011-03-08 09:47:30 UTC
What we really need is a fix for this bug in a newer upstream snapshot we can then upgrade to, not reverting to older code.

Can you please post the output of:
grep NetworkManager /var/log/messages | tail -n 50
(i.e. the last 50 lines of /var/log/messages containing "NetworkManager", you should see from the timestamps whether 50 is the right number or whether it's better to post more or less) after you try to connect and fail?

Having the same output after a successful connection for comparison could also be useful.

Comment 3 Rex Dieter 2011-03-08 18:55:26 UTC
This landed approx at the same time, perhaps relevant?
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.997-1.fc14

Maybe try downgrading that to test as well?

Comment 4 Germano Massullo 2011-03-08 18:56:44 UTC
Created attachment 482987 [details]
grep NetworkManager /var/log/messages | tail -n 50

Comment 5 Germano Massullo 2011-03-08 18:57:43 UTC
Affects also WPA connections.

NetworkManager-0.8.3.997-1.fc14.i686
kde-plasma-networkmanagement-0.9-0.35.20110221.fc14.i686
Thinkpad T60

Comment 6 Germano Massullo 2011-03-08 21:12:32 UTC
Now submitting another log (this time of a Thinkpad R500)

NetworkManager-0.8.3.997-1.fc14.x86_64
kde-plasma-networkmanagement-0.9-0.35.20110221.fc14.x86_64

Comment 7 Germano Massullo 2011-03-08 21:13:19 UTC
Created attachment 483019 [details]
grep NetworkManager /var/log/messages | tail -n 50 of Thinkpad R500

Comment 8 Andrei Gaponenko 2011-03-09 06:05:12 UTC
Kevin and everyone, thank you for your replies.

Here is more information - and a workaround.

First of all, the problem is indeed KDE specific.
From GNOME I can connect to the network without a glitch.

Now the KDE part.

The WEP passphrase on my network is not valuable enough to warrant
typing in an extra password to connect, thus it was stored 
"in file (unencrypted)"  according to NetworkManager "other"
settings.   And the whole KDE Wallet subsystem was disabled.
It is this setup that got broken by the update.

After enabling the KDE Wallet subsystem, switching NetworkManager
to store secrets there, and some trying (logging out/in ...)
I managed to establish the WiFi connection from KDE.
Thus the workaround is to switch to using it.
This is a pretty annoying workaround, because one needs 
to enter a password one more time.  But it works for me.

I hope this newly introduced bug will be fixed - there 
are reasons to use the unencrypted storage!

Regards,
Andrei

Comment 9 Germano Massullo 2011-03-09 09:05:00 UTC
Logs I entered are about KDE with KDE wallet disabled

Comment 10 Kevin Kofler 2011-03-09 13:05:02 UTC
> This is a pretty annoying workaround, because one needs 
> to enter a password one more time.

You can have a passwordless wallet. I think you can even use kwalletmanager to set up a dedicated wallet for kde-plasma-networkmanagement if you don't want your main wallet to be passwordless.


This is interesting, because we had 2 reports on IRC of issues with VPN authentication due to the kde-plasma-networkmanagement update, and there, switching FROM KWallet TO unencrypted plaintext storage worked around it successfully.


I wonder if there was some incompatible change to the way (some) passwords are stored. Can you try reenabling KWallet, then reentering the password in the configuration dialog and OKing the change?

Comment 11 Andrei Gaponenko 2011-03-09 17:41:20 UTC
Hi Kevin,

> Can you try reenabling KWallet, then reentering the password in the configuration dialog and OKing the change?

Not sure I understand what you ask me to test. With KDE Wallet re-enabled
and used by NetworkManager I can connect to the WEP network, see Comment #8.

I also created a new user account and see that:

- connecting to the WEP network works with the default setting (using KWallet).

- NetworkManager won't switch to using unencrypted storage while KWallet
  is available:  I can choose the unencrypted 
  setting in the configuration and click "apply",  however after closing and
  re-opening the configuration dialog I see the setting is reverted back 
  to using KWallet.

- I the KWallet subsystem is disabled, NetworkManager can be switched 
  to using unencrypted storage.  E.g. the configuration change will 
  stay and not reset back.  However the actual connection won't work,
  one gets stuck in the "Waiting for authentication" state.

Regards,
Andrei

Comment 12 Kevin Kofler 2011-03-11 11:05:31 UTC
*** Bug 684022 has been marked as a duplicate of this bug. ***

Comment 13 Kevin Kofler 2011-03-12 03:23:43 UTC
*** Bug 683603 has been marked as a duplicate of this bug. ***

Comment 14 Emerson Burris 2011-03-12 03:33:11 UTC
My output of /var/log/messages is identical. I have been unable to get the connection to work with any setting in KDE Wallet. Here is my output of wpa_supplicant:


Trying to associate with 00:18:39:e5:6d:1b (SSID='Burris' freq=2437 MHz)
Associated with 00:18:39:e5:6d:1b
WPA: Key negotiation completed with 00:18:39:e5:6d:1b [PTK=TKIP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 00:18:39:e5:6d:1b completed (auth) [id=0 id_str=]
WPA: Group rekeying completed with 00:18:39:e5:6d:1b [GTK=TKIP]
WPA: Group rekeying completed with 00:18:39:e5:6d:1b [GTK=TKIP]
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Failed to initiate AP scan.

Comment 15 Germano Massullo 2011-03-12 15:56:35 UTC
On my Thinkpad T60:

First experiment, KDE wallet disabled. Trying to erase the known wifi connection and re-enter the password. Nothing.

logout from KDE.
Login in KDE

Second experiment: trying to enable KDE wallet and then enter again the password of the wifi. The computer connects well.

logout from KDE.
Login in KDE

Thrid experiment: trying again without KDE wallet. Computer does not connect.

Comment 16 Paulo Fidalgo 2011-03-14 10:21:57 UTC
I'm having trouble with VPN connections too. My workaround is to do not store the password and every time it connects ask it.
Although my Wifi passwords are remembered.

Comment 17 Jirka Klimes 2011-03-14 14:43:40 UTC
I've attached a patch fixing the bug to
https://git.reviewboard.kde.org/r/100855

Comment 18 Rex Dieter 2011-03-14 14:48:22 UTC
Thanks!

will make some test-builds asap.

Comment 19 Germano Massullo 2011-03-14 15:06:14 UTC
I experimented the bug on a third computer, and the previous procedure that I have entered works well.
When Paulo Fidalgo patch will be relased on stable repositories?

Comment 20 Fedora Update System 2011-03-14 18:09:04 UTC
kde-plasma-networkmanagement-0.9-0.39.20110314.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/kde-plasma-networkmanagement-0.9-0.39.20110314.fc15

Comment 21 Fedora Update System 2011-03-14 18:09:32 UTC
kde-plasma-networkmanagement-0.9-0.39.20110314.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/kde-plasma-networkmanagement-0.9-0.39.20110314.fc14

Comment 22 Fedora Update System 2011-03-14 18:11:22 UTC
kde-plasma-networkmanagement-0.9-0.39.20110314.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/kde-plasma-networkmanagement-0.9-0.39.20110314.fc13

Comment 23 Fedora Update System 2011-03-19 05:47:24 UTC
kde-plasma-networkmanagement-0.9-0.39.20110314.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Kevin Kofler 2011-03-22 21:12:30 UTC
I think this bug is actually conflating 2 different regressions:
1. WEP/WPA worked ONLY with KWallet, this is reportedly fixed now.
2. VPN, on the other hand, works only if you DON'T use KWallet, and this is reportedly NOT fixed yet.
See also comment #10.

IMHO, breakage with KWallet enabled is the worse regression, though VPN is less common. We really need the second regression fixed too.

I'm going to file a separate bug for the VPN issue.

Comment 25 Kevin Kofler 2011-03-22 21:25:39 UTC
The VPN issue is now bug #689964. So if you're experiencing that particular issue, you will want to CC yourself on that bug. (I already CCed 2 people who reported having that issue there.)

Comment 26 Fedora Update System 2011-03-23 22:55:00 UTC
kde-plasma-networkmanagement-0.9-0.39.20110314.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 27 Fedora Update System 2011-03-23 22:55:18 UTC
kde-plasma-networkmanagement-0.9-0.39.20110314.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 28 Emerson Burris 2011-03-24 00:23:03 UTC
kde-plasma-networkmanagement-0.9-0.39.20110314.fc15 update worked flawlessly. Computer connects well with KDEwallet disabled.

Comment 29 ah.javier 2011-03-24 21:30:11 UTC
Just made the update for kde-plasma-networkmanagement, network still doesnt work without kde wallet in fedora 14.

Comment 30 Kevin Kofler 2011-03-24 22:17:24 UTC
Can you please try kde-plasma-networkmanagement-0.9-0.40.20110323.fc14 from updates-testing? This has both a slightly different fix (from upstream) for this issue and the fix for bug #689964.

Comment 31 ah.javier 2011-03-24 22:37:06 UTC
Just installed:
kde-plasma-networkmanagement-0.9-0.40.20110323.fc14.i686.rpm
kde-plasma-networkmanagement-libs-0.9-0.40.20110323.fc14.i686.rpm

Same results..


Note You need to log in before you can comment on or make changes to this bug.