[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus when using a proxy
https://bugs.kde.org/show_bug.cgi?id=449984 Daniel Albers changed: What|Removed |Added CC||el...@seznam.cz --- Comment #19 from Daniel Albers --- *** Bug 419213 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus when using a proxy
https://bugs.kde.org/show_bug.cgi?id=449984 Daniel Albers changed: What|Removed |Added CC||dan...@lbe.rs --- Comment #18 from Daniel Albers --- (In reply to Kai Uwe Broulik from comment #17) > On my system I also noticed apps getting stuck, I then found that kded5 was > in a deadlock. > > I had the geolocation observer try to update the location (for nightcolor), > which then did a TransferJob, which in turn used KIO, which would then do > the proxy stuff. It then called into ProxyScout, ending up in itself (since > kded called to kded), it then called KProtocolManager::proxyType(), which > deadlocked trying to acquire a mutex, see backtrace: > > Disabling either network proxy config or geolocatoin kded modules in > systemsettings removed the freeze but obviously that's not a fix. +1, exact same behavior on kio 5.96.0, plasma-workspace-5.25.4. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus when using a proxy
https://bugs.kde.org/show_bug.cgi?id=449984 Kai Uwe Broulik changed: What|Removed |Added CC||k...@privat.broulik.de --- Comment #17 from Kai Uwe Broulik --- On my system I also noticed apps getting stuck, I then found that kded5 was in a deadlock. I had the geolocation observer try to update the location (for nightcolor), which then did a TransferJob, which in turn used KIO, which would then do the proxy stuff. It then called into ProxyScout, ending up in itself (since kded called to kded), it then called KProtocolManager::proxyType(), which deadlocked trying to acquire a mutex, see backtrace: Disabling either network proxy config or geolocatoin kded modules in systemsettings removed the freeze but obviously that's not a fix. #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7f6e74dce7a5 in QtLinuxFutex::_q_futex(int*, int, int, unsigned long long, int*, int) (val3=0, addr2=0x0, val2=0, val=3, op=0, addr=0x7f6e6b921340 <(anonymous namespace)::Q_QGS_kProtocolManagerPrivate::innerFunction()::holder>) at /home/kaiuwe/kde/src/Qt5/qtbase/src/corelib/thread/qfutex_p.h:133 #2 QtLinuxFutex::futexWait >(QBasicAtomicPointer&, QBasicAtomicPointer::Type) (expectedValue=0x3, futex=...) at /home/kaiuwe/kde/src/Qt5/qtbase/src/corelib/thread/qfutex_p.h:135 #3 lockInternal_helper (timeout=-1, elapsedTimer=0x0, d_ptr=...) at /home/kaiuwe/kde/src/Qt5/qtbase/src/corelib/thread/qmutex_linux.cpp:142 #4 QBasicMutex::lockInternal() (this=0x7f6e6b921340 <(anonymous namespace)::Q_QGS_kProtocolManagerPrivate::innerFunction()::holder>) at /home/kaiuwe/kde/src/Qt5/qtbase/src/corelib/thread/qmutex_linux.cpp:159 #5 0x7f6e74dce99e in QMutex::lock() (this=this@entry=0x7f6e6b921340 <(anonymous namespace)::Q_QGS_kProtocolManagerPrivate::innerFunction()::holder>) at /home/kaiuwe/kde/src/Qt5/qtbase/src/corelib/thread/qmutex.cpp:237 #6 0x7f6e6b86cd84 in QMutexLocker::QMutexLocker(QBasicMutex*) (m=, this=) at /home/kaiuwe/kde/qt5/include/QtCore/qmutex.h:238 #7 KProtocolManager::proxyType() () at /home/kaiuwe/kde/src/kio/src/core/kprotocolmanager.cpp:379 #8 0x7f6e6861aedf in KPAC::ProxyScout::startDownload() (this=0x55b7c7ee5bd0) at /home/kaiuwe/kde/src/kio/src/kpac/proxyscout.cpp:180 #9 0x7f6e6861c2e8 in KPAC::ProxyScout::proxiesForUrl(QString const&, QDBusMessage const&) (this=this@entry=0x55b7c7ee5bd0, checkUrl=..., msg=...) at /home/kaiuwe/kde/qt5/include/QtCore/qstringlist.h:116 #10 0x7f6e6861a1f0 in KPAC::ProxyScout::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=_o@entry=0x55b7c7ee5bd0, _id=_id@entry=1, _a=_a@entry=0x7ffed342dfc0, _c=QMetaObject::InvokeMetaMethod) at /home/kaiuwe/kde/build/kio/src/kpac/kded_proxyscout_autogen/EWIEGA46WW/moc_proxyscout.cpp:108 #11 0x7f6e6861a631 in KPAC::ProxyScout::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_a=0x7ffed342dfc0, _id=1, _c=QMetaObject::InvokeMetaMethod, _o=0x55b7c7ee5bd0) at /home/kaiuwe/kde/build/kio/src/kpac/kded_proxyscout_autogen/EWIEGA46WW/moc_proxyscout.cpp:168 #12 KPAC::ProxyScout::qt_metacall(QMetaObject::Call, int, void**) (this=0x55b7c7ee5bd0, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7ffed342dfc0) at /home/kaiuwe/kde/build/kio/src/kpac/kded_proxyscout_autogen/EWIEGA46WW/moc_proxyscout.cpp:168 #13 0x7f6e753ab54b in QDBusConnectionPrivate::deliverCall(QObject*, int, QDBusMessage const&, QVector const&, int) (this=, object=, msg=..., metaTypes=..., slotIdx=) at /home/kaiuwe/kde/src/Qt5/qtbase/src/dbus/qdbusintegrator.cpp:1001 #14 0x7f6e753b09d7 in QDBusConnectionPrivate::activateCall(QObject*, int, QDBusMessage const&) (this=this@entry=0x7f6e64003a00, object=0x55b7c7ee5bd0, flags=241, msg=...) at /home/kaiuwe/kde/src/Qt5/qtbase/src/dbus/qdbusintegrator.cpp:904 #15 0x7f6e753b10ff in QDBusConnectionPrivate::activateCall(QObject*, int, QDBusMessage const&) (msg=..., flags=, object=, this=0x7f6e64003a00) at /home/kaiuwe/kde/src/Qt5/qtbase/src/dbus/qdbusintegrator.cpp:853 --Type for more, q to quit, c to continue without paging-- #16 QDBusConnectionPrivate::activateObject(QDBusConnectionPrivate::ObjectTreeNode&, QDBusMessage const&, int) (pathStartPos=, msg=..., node=..., this=0x7f6e64003a00) at /home/kaiuwe/kde/src/Qt5/qtbase/src/dbus/qdbusintegrator.cpp:1521 #17 QDBusConnectionPrivate::activateObject(QDBusConnectionPrivate::ObjectTreeNode&, QDBusMessage const&, int) (this=0x7f6e64003a00, node=..., msg=..., pathStartPos=) at /home/kaiuwe/kde/src/Qt5/qtbase/src/dbus/qdbusintegrator.cpp:1447 #18 0x7f6e753b1a80 in QDBusConnectionPrivate::handleObjectCall(QDBusMessage const&) (this=this@entry=0x7f6e64003a00, msg=...) at /home/kaiuwe/kde/src/Qt5/qtbase/src/dbus/qdbusintegrator.cpp:1596 #19 0x7f6e753b1cca in QDBusConn
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus when using a proxy
https://bugs.kde.org/show_bug.cgi?id=449984 postix changed: What|Removed |Added CC||pos...@posteo.eu -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus when using a proxy
https://bugs.kde.org/show_bug.cgi?id=449984 xmhjnat...@gmail.com changed: What|Removed |Added CC||xmhjnat...@gmail.com --- Comment #16 from xmhjnat...@gmail.com --- (In reply to Nicolas Fella from comment #6) > (In reply to steveb from comment #5) > > Looking at KDED source, it possibly could be that the KDED plugins are not > > being loaded properly? I can not tell. > You can check that using "qdbus org.kde.kded5 /kded > org.kde.kded5.loadedModules", make sure it contains networkmanagement > > > How can I see Qt logger messages? If I can enable & see them, I might be > > able to see what is going on. > > Using journalctl. Also you can use > https://invent.kde.org/utilities/kdebugsettings to control what gets logged When the ProxyType workaround is not applied, qdbus just gets stuck totally and shows nothing -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus when using a proxy
https://bugs.kde.org/show_bug.cgi?id=449984 Enrico Tagliavini changed: What|Removed |Added CC||enrico.tagliav...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus when using a proxy
https://bugs.kde.org/show_bug.cgi?id=449984 Luigi Toscano changed: What|Removed |Added CC||luigi.tosc...@tiscali.it --- Comment #15 from Luigi Toscano --- (In reply to steveb from comment #12) > I found that the System Setting "Detect proxy configuration automatically" > was causing it for me. > > Setting is saved in file ~/.config/kioslaverc > Removing the file, or changing [Proxy Settings] ProxyType from 3 to 0 will > fix a broken system. > > However, setting the same Proxy setting on a 5.24 system will not break it. I confirm this workaround on Fedora 35 too. I just upgraded from Plasma 5.23.5 to 5.24.2 and Frameworks 5.90 to 5.91 on Fedora 35 and I had to use this workaround too. I had ProxyType=2 and a custom Proxy Config Script. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus when using a proxy
https://bugs.kde.org/show_bug.cgi?id=449984 Nate Graham changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED Summary|Plasma 5.24.0 |Plasma 5.24.0 |NetworkManager cannot get |NetworkManager cannot get |secrets using DBus |secrets using DBus when ||using a proxy -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #14 from zhaozihan...@163.com --- (In reply to steveb from comment #12) > I found that the System Setting "Detect proxy configuration automatically" > was causing it for me. > > Setting is saved in file ~/.config/kioslaverc > Removing the file, or changing [Proxy Settings] ProxyType from 3 to 0 will > fix a broken system. > > However, setting the same Proxy setting on a 5.24 system will not break it. Oh, this workaround also worked for me. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #13 from Dmitrii Chermnykh --- (In reply to steveb from comment #12) > I found that the System Setting "Detect proxy configuration automatically" > was causing it for me. > > Setting is saved in file ~/.config/kioslaverc > Removing the file, or changing [Proxy Settings] ProxyType from 3 to 0 will > fix a broken system. > > However, setting the same Proxy setting on a 5.24 system will not break it. This also fixed the problem for me -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #12 from steveb --- I found that the System Setting "Detect proxy configuration automatically" was causing it for me. Setting is saved in file ~/.config/kioslaverc Removing the file, or changing [Proxy Settings] ProxyType from 3 to 0 will fix a broken system. However, setting the same Proxy setting on a 5.24 system will not break it. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 chermnykh2...@gmail.com changed: What|Removed |Added CC||chermnykh2...@gmail.com --- Comment #11 from chermnykh2...@gmail.com --- Can confirm on 5.24.1 archlinux In my case networkmanager works fine, but other components break: - system tray - keyboard layout switching - global menu - notifications - kscreen On clean user account system works fine so the problem is due to some user configuration. Rolling `plasma-workspace` back to 5.23.5 fixes the problem -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 Jonathan Doman changed: What|Removed |Added CC||jonathan.do...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #10 from steveb --- Yes, plasma-workspace. I tried another user account, and things were working properly with it, so it's not a system thing. I found that there is something in ~/.config that is causing this. Starting with an empty .config directory got everything working again. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #9 from Nicolas Fella --- > After downgrading plasma-desktop and plasma-workspace to 5.23.5 (in the > meanwhile the plasma-nm is still 5.24.0) the problem is gone. I'd say it's much more likely to be caused by plasma-workspace than plasma-desktop. Ideally someone would perform a git bisect on it -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #8 from Nicolas Fella --- (In reply to steveb from comment #7) > The kded plugins are in: /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded > How does kded5 find them? The relevant code is at https://invent.kde.org/frameworks/kded/-/blob/master/src/kded.cpp#L132 However, it doesn't sound like the module is not loaded. I tried manually disabling the module in the background services settings and the symptoms are different, the connection attempt fails instantly. It sounds like there is some generic problem with kded, not specifically the network module. this would also match this: > After downgrading plasma-desktop and plasma-workspace to 5.23.5 (in the > meanwhile the plasma-nm is still 5.24.0) the problem is gone. So maybe the > problem isn't related to plasma-nm? -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #7 from steveb --- (In reply to Nicolas Fella from comment #6) Looking for loaded modules failed, using "qdbus org.kde.kded5 /kded org.kde.kded5.loadedModules" > Error: org.freedesktop.DBus.Error.NoReply Enabling debug messages with kdebugsettings, I see only: > klauncher[1346]: kf.init.klauncher: new app "org.kde.kded5" I would expect to also see DEBUG messages like "Successfully loaded module ", but there are none. The kded plugins are in: /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded How does kded5 find them? -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #6 from Nicolas Fella --- (In reply to steveb from comment #5) > Looking at KDED source, it possibly could be that the KDED plugins are not > being loaded properly? I can not tell. You can check that using "qdbus org.kde.kded5 /kded org.kde.kded5.loadedModules", make sure it contains networkmanagement > How can I see Qt logger messages? If I can enable & see them, I might be > able to see what is going on. Using journalctl. Also you can use https://invent.kde.org/utilities/kdebugsettings to control what gets logged -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #5 from steveb --- An upgrade today to Plasma 5.24.1 & Frameworks 5.91.0 has not changed behavior. Nicholas, See Comment 1 - It's a problem with KDED, where it is not responding properly to D-Bus message. Looking at KDED source, it possibly could be that the KDED plugins are not being loaded properly? I can not tell. How can I see Qt logger messages? If I can enable & see them, I might be able to see what is going on. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #4 from Nicolas Fella --- (In reply to zhaozihanrxh from comment #2) > This happens on my Arch Linux. Here is my journalctl: https://fars.ee/lZ7A Relevant looking part of the logs: 2月 14 14:47:48 ME-HASEE NetworkManager[525]: [1644821268.8667] device (wlp0s20f3): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') 2月 14 14:47:48 ME-HASEE NetworkManager[525]: [1644821268.8670] device (wlp0s20f3): Activation: (wifi) access point 'HONOR 9X HULK' has security, but secrets are required. 2月 14 14:47:48 ME-HASEE NetworkManager[525]: [1644821268.8670] device (wlp0s20f3): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed') 2月 14 14:47:48 ME-HASEE NetworkManager[525]: [1644821268.8675] device (wlp0s20f3): no secrets: No agents were available for this request. 2月 14 14:47:48 ME-HASEE NetworkManager[525]: [1644821268.8675] device (wlp0s20f3): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed') 2月 14 14:47:48 ME-HASEE NetworkManager[525]: [1644821268.8677] manager: NetworkManager state is now DISCONNECTED 2月 14 14:47:48 ME-HASEE NetworkManager[525]: [1644821268.8679] device (wlp0s20f3): Activation: failed for connection 'HONOR 9X HULK' -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 Nicolas Fella changed: What|Removed |Added CC||nicolas.fe...@gmx.de --- Comment #3 from Nicolas Fella --- I can't reproduce this, wifi and VPN passwords work fine on all of my systems -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 --- Comment #2 from zhaozihan...@163.com --- New here, hope my comment is useful. If I violate the rules, please tell me... This happens on my Arch Linux. Here is my journalctl: https://fars.ee/lZ7A In addition, if I manage to keep my WiFi password not encrypted I can connect to it. After downgrading plasma-desktop and plasma-workspace to 5.23.5 (in the meanwhile the plasma-nm is still 5.24.0) the problem is gone. So maybe the problem isn't related to plasma-nm? Operating System: Arch Linux KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.8-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 Nate Graham changed: What|Removed |Added Keywords||regression CC||k...@davidedmundson.co.uk, ||n...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 449984] Plasma 5.24.0 NetworkManager cannot get secrets using DBus
https://bugs.kde.org/show_bug.cgi?id=449984 steveb changed: What|Removed |Added Summary|Plasma 5.24.0 |Plasma 5.24.0 |NetworkManager not working |NetworkManager cannot get |with kdewallet |secrets using DBus --- Comment #1 from steveb --- I have used "dbus-monitor --system" to investigate. The call to GetSecrets does not get a reply: > method call time=1644566969.208756 sender=:1.11 -> destination=:1.48 > serial=3114 path=/org/freedesktop/NetworkManager/SecretAgent; > interface=org.freedesktop.NetworkManager.SecretAgent; member=GetSecrets In my case :1.48 is /usr/bin/kded5 and it should respond to interface=org.freedesktop.NetworkManager.SecretAgent On another working machine (kubuntu 21.10, 5.22.5, 5.86) the method reply contains the secret (the password). Using "d-feet" I find that viewing any DBus named "org.kde..." or ":1.xxx" for any kde related process hangs "Introspecting..." Neither the Name: or Unique name: fields are populated. -- You are receiving this mail because: You are watching all bug changes.
