Bug 280753 - After crash password of connection was lost
Summary: After crash password of connection was lost
Status: RESOLVED UNMAINTAINED
Alias: None
Product: knetworkmanager
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: 0.9
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: Will Stephenson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-25 07:24 UTC by O Kullmann
Modified: 2018-09-03 04:05 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description O Kullmann 2011-08-25 07:24:39 UTC
Version:           0.9 (using KDE 4.6.0) 
OS:                Linux

The system crashed (this happens on average every 3 days now), and upon
restarting (after reboot) a long-established connection, with was used many times,
and stored as a named connection, had apparently lost its password, that is,
the blanck box opened with the password to enter.

Reproducible: Didn't try

Steps to Reproduce:
I tried for a long time to establish where the crashes come from, but to
no avail at all. So no chance to reproduce it.
With previous crashes no information was lost.

Actual Results:  
It is strange that one is forced to enter here something.

Expected Results:  
KWallet asks to enter the password (this can't be done when launching KDE,
since KDE doesn't recognise the keyboard at that time), after that the
wireless connection is established, without asking for the wpa(2)-password.

By the way, when I now go into the KNetworkManager to inspect the information,
again and again KWallet asks for the password. Perhaps then actually the
KWallet-ask-box disappears, but that is not so easy to tell, since KWallet
always opens on some other virtual desktop, you never know which, and one has
to run through all of them to find it. Sometimes these windows hide behind
other windows.

OS: Linux (x86_64) release 2.6.39.3-0.5-desktop
Compiler: gcc

Since one year I try to use KDE4, first under Suse 11.3, then under Suse 11.4
It is a permanent minefield. And I can't see any attempts to solve any of
the problems I encounter (and some of them I report here, but apparently without
any effect). Before that I used, on my old laptop, for >5 years Suse 9.2 with
the KDE which came with it, and I was very happy with it. Just a few days ago
I deleted the harddisk from the now nearly completely broken old laptop, started
a last time KDE3, and marvelled a last time how it all worked. I fear KDE
will never again get back to this state, since instead of fixing bugs, and
concentrating on the desktop, new stuff is added, which will just make things
worse.

The most obvious thing KDE should do is to ACKNOWLEDGE its broken state, and
care for that. That is, one needs the possibility to store and inspect all
the configuration (whatevery it is, just everything) explicitly, as part of
the KDE service. Not somewhere hidden in some hidden folders, but under full
control, based on standard Linux/Unix tools. Not saving state when the desktop
feels to do it, but also when the user says so. The Linux filesystem is reliable, but not KDE. For example the badly designed KNetwork-connections
management: very easily something is deleted, and that could be a very SERIOUS
problem for some who at a very special moment in time absolutely rely on the
service being available. So every connection should be stored in its own file,
clearly specified where this file is, and I could then just make the file
non-writeable to disable by accident change or removal.
Comment 1 Christoph Feck 2011-08-25 12:33:10 UTC
If the crash still happens with a recent KDE version (4.6.5 or 4.7), please add the backtrace. For more information, see http://techbase.kde.org/User:DarioAndres/How_to_provide_more_information_about_crash_reports

Additionally, if you are really still using KNetworkManager, you should try the network management plasmoid instead, as all bug fixes in the last year only went to that.
Comment 2 O Kullmann 2011-08-25 12:40:54 UTC
There is a misunderstanding: the crash likely had nothing to do with
KNetworkManager (of course I don't know, but I have no reasons to believe that
there is a connection). The problem was that then, after restarting, apparently
the password managed by KNetworkManager was lost.
Comment 3 O Kullmann 2011-08-25 12:53:50 UTC
Regarding "if you are really still using KNetworkManager", how can I check
this? In the taskbar, there is the section with the symbols for the devices,
and there is the symbol for network-connections: all what one can do with
these incomplete things is to click a bit, but they don't tell you their
name, version number etc. Also the good old right-click disappeard, just
left-clicking for some actions. Clicking on "Manage Connections" one gets
"Configure -- KDE Control Module", and clicking then on "Help" just yields
"Documentation not found".

According to Internet-information the plasmoid is just an interface to
KNetworkManager. Also Yast speaks about NetworkManager. In order to
obtain some information I used

kullmann-0:~> knetworkmanager --version
Qt: 4.7.1
KDE Development Platform: 4.6.00 (4.6.0) "release 6"
KNetworkManager: v0.9
Comment 4 Andrew Crouthamel 2018-09-03 04:05:03 UTC
Hello! Sorry to be the bearer of bad news, but this project has been
unmaintained for many years and I will be closing this bug.