I’m on CachyOS and was using KRDP to connect to my laptop from my Windows instance. Connection was always a wee bit finnicky, but ultimately got the job done.
However last night there appears to have been an update to KRDP (6.7.0) and now I can’t seem to connect any more.
From the Windows RPD client things look OK, connection is being established, then a black screen and then nothing.
Running krdpserver from a console and trying to connect I get the following:
krdpserver -u shaamaan -p test --plasma
qt.qpa.services: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: App info not found for 'org.kde.krdp-server'")
[22:33:04:956] [5294:000014ae] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x56440b95af50]: *************************************************
[22:33:04:956] [5294:000014ae] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x56440b95af50]: This build is using [experimental] build options:
[22:33:04:956] [5294:000014ae] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x56440b95af50]: * 'WITH_VAAPI=ON'
[22:33:04:956] [5294:000014ae] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x56440b95af50]: * 'WITH_VAAPI_H264_ENCODING=ON'
[22:33:04:956] [5294:000014ae] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x56440b95af50]: *
[22:33:04:956] [5294:000014ae] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x56440b95af50]: [experimental] build options might crash the application
[22:33:04:956] [5294:000014ae] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x56440b95af50]: *************************************************
[22:33:05:044] [5294:0000154f] [ERROR][com.freerdp.core.rdp] - [tpkt_ensure_stream_consumed_][0x56440b95af50]: [rdp_read_info_packet] Received invalid TPKT header length 586, 196 bytes too long!
org.kde.krdp: New client connected: Windows platform Windows NT
[22:33:12:527] [5294:0000154f] [ERROR][com.freerdp.api] - [rdp_peer_handle_state_active]: PostConnect for peer 0x56440b762f80 failed
[22:33:12:527] [5294:0000154f] [ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1]
Same here but I can’t connect from a Linux machine and the notification system is spamming that a conection is initiated every 3-4 seconds. I tried different ports, enabling and disabling service, many restarts to no avail. Krdo doesn’t work at all after upgrade to Plasma 6.7.
I noticed the same issues with my KRDP server after upgrading to Plasma 6.7. I’m hoping to add some additional details here in case it can help the dev team solve the issue, but in the meantime I did find a workaround.
For context, I’m currently running KDE Plasma on Fedora 44, and have the Remote Desktop service set to start automatically at login. The only user on my machine is set up as a Remote Desktop user.
First I checked the logs (journalctl --user -fu app-org.kde.krdpserver.service) and found that it was reporting an authentication failure for some reason when I attempted to establish a connection (client showed a black screen and closed right away). Adding a second user/password and restarting the service allowed me to remote into my machine again. To me, this indicates that there’s some sort of issue with authenticating the default user after the upgrade to 6.7. The logs I found are below:
Jun 21 10:44:25 HOSTNAME krdpserver[5289]: New client connected: Unspecified platform Unspecified version
Jun 21 10:44:25 HOSTNAME unix_chkpwd[5791]: check pass; user unknown
Jun 21 10:44:25 HOSTNAME unix_chkpwd[5791]: password check failed for user (user)
Jun 21 10:44:25 HOSTNAME krdpserver[5289]: pam_unix(login:auth): authentication failure; logname=user uid=1000 euid=1000 tty= ruser= rhost= user=user
Jun 21 10:44:27 HOSTNAME krdpserver[5289]: pam_authenticate failure: Authentication failure
Jun 21 10:44:27 HOSTNAME krdpserver[5289]: [10:44:27:659] [5289:00001683] [ERROR][com.freerdp.api] - [rdp_peer_handle_state_active]: PostConnect for peer 0x5621db46f160 failed
Jun 21 10:44:27 HOSTNAME krdpserver[5289]: [10:44:27:659] [5289:00001683] [ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1]
Jun 21 10:45:12 HOSTNAME systemd[1870]: Stopping app-org.kde.krdpserver.service - KRDP Server...
Jun 21 10:45:12 HOSTNAME systemd[1870]: Stopped app-org.kde.krdpserver.service - KRDP Server.
Jun 21 10:45:12 HOSTNAME systemd[1870]: Starting app-org.kde.krdpserver.service - KRDP Server...
Jun 21 10:45:12 HOSTNAME systemd[1870]: Started app-org.kde.krdpserver.service - KRDP Server.
Unclear to me if my fix will be relevant to everyone, but try adding a second temporary user/password and restart the service. Then log in using those credentials. See if that works in the meantime to restore functionality.
I experienced the same issue. I was able to work around it:
Sparky said: try adding a second temporary user/password and restart the service
Regarding ^^ this advice, in the KDE System Settings for Remote Desktop, I “unchecked” my user and then clicked “Add New” and added the same user’s username and password manually.
I’m on CachyOS. Somehow the KWallet integration is slightly broken somehow
That works for just getting a connection, but even afterwards the screen is empty (black on KRDC/xFreeRDP, white on wlFreeRDP). Controls work fine though. Using Fedora 44 KDE, tried both with and without rpmfusion codecs. Without codecs, it understandably complained about the lack of a H264 codec. It doesn’t work with them either though.
Same issues here. Had to add a new user specifically in the krdp settings, just enabling the built-in user no longer works.
Another new issue in 6.7: frequent issues where sometime after connecting the krdp desktop no longer responds.
Existing issue pre-6.7 and 6.7 that continues: many cases of a “stuck key” where some arrow for ex. keeps repeating until I tap another key. Not a keyboard issue, it’s a krdp issue.
VNC (krfb) is also bad but has different issues. Sometimes doesn’t connect. Sometimes the screen stops updating until reboot. Significantly laggier than krdp. On the + side no repeated key issues.
As a longterm Linux server admin but new explorer of KDE as a desktop, I appreciate what KDE has done over 30 years. Still has a long looong way to go imo compared to MacOS, though of course “FREEDOM!”. Remote access is bad imo (other than ssh), after decades of Xorg Wayland comes in with a 10 year dev cycle and still missing a lot of functionality and causing a bunch of new issues. BTW rdp on Gnome was excellent imo, much less laggy than KDE rdp (on a gig LAN), no connection issues, no repeated key issues. One good aspect of Gnome.
Discussed here and in a bunch of other bug reports with workarounds provided. Issue is triggered by changes made related to pam and to mitigate potential future exploits.
Surprising this wasn’t discovered earlier/before release but it’s fair to assume no one uses kde or remote desktop for important server work so it’s not going to cause business/enterprise issues for anyone. Overall I’d prefer to use Tiger VNC over any of these fairly new and fairly bad remote solutions built into desktops, but Tiger VNC doesn’t work with Wayland (it’s supposed to have added Wayland support in 1.16, we’ll see).
While this works I can’t shake the feeling that RDP in KDE is now… iffy.
Example:
with the workaround I can connect fine and start RDP; since the machine I’m connecting to is 1m away from me I can see the mouse moving and all that…
after a random amount of time the RDP client I’m using will no longer update what’s happening on the host screen; it’ll still send mouse position / keyboard / clicks (I can turn my head and see the mouse moving and my commands being executed)
It’s definitely not an issue with the connection quality, as it’s all on the same WiFi, and Windows RDP server on the same hardware (dual-boot setup) works flawlessly.