There are a couple of D-Bus tools that can do that, e.g. qdbusviewer (usually in some Qt dev package), d-feet, and various command line tools.
However, in this case they would probably not be much help since the error says that an object (D-Bus end point) is missing.
I.e. the UI thinks there should be a corresponding Settings object on the NetworkManager side but apparently there isn’t.
This could potentially be solved by restarting the UI (probably logout/login) so that it has to query NM again or using a different frontend, e.g. nmcli for the command line.
Or removing the hotspot config and re-creating it.
Path in this case is not a file system path.
It is part of a D-Bus end point address.
Essentially each D-Bus service has a name, which is the primary address.
Within that connection a client can address specific end point objects using a “D-Bus path”.
Such a path looks like a file system path but is “virtual” within the service..
A way to point to an object within a tree of objects.
@krake, I was referring to the .psk file referenced in the other notification, but thank you. (I do wish there were a virtual DBus filesystem, like there is for devices in /dev!)
I’d run qdbus org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndReboot, and that indeed remediated the inconsistency between kcm_networkmanagement and plasmashell. However, it’s achieved that by merely reverting my password, and it reproduces:
I can try restarting the service if that’d help narrow this, but it looks like 3 problems:
The Network KCM might not refresh upon preference application failure, and silently fails when something fails, unlike the Plasmoid.
The plasmoid fails to access these preferences, irrespective of whether the KCM does.
There’s also that the “Hotspot” button remains activated when it’s not, if the last attempt to activate it failed. You can see that at the start of the video.
I’d try to report these, but I’ve no idea of what causes them, and there’s rather too many problems to report for me to have the time to fill the BZ template for each.
Maybe also check which version if network-manager you have.
Probably a very new one since you are on Fedora.
I am on 1.46 since I am KDE Neon which, for base OS stuff, is essentially Ubuntu LTS 24.04
Yes.
Basically testing if just changing the password fails or if the hotspot does not work even when created with a valid password.
Might even be a difference if one tries to change from a valid to a new valid password and only setup with a non-valid password causes the change issue later.
I remember experiencing this > 3 years ago on an old laptop that I still have, and expecting that it was due to its aged hardware. However, on a Framework 16? It can’t have that poor of a Wi-Fi chip!
