Created attachment 166779 [details] BLUE SCREEN OF KRDC SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Install Artix linux and use KRDC for a year without problems 2. a year later do sudo pacman -Syu 3. Plasma 6 installs 4. Attempt to use KRDC to RDP into Windows machine. The connection succeeds, but it only shows a blue screen. OBSERVED RESULT BLUE SCREEN THAT DOES NOT SHOW ANYTHING EXPECTED RESULT BEING ABLE TO SEE THE MACHINE I RDP'd TO SOFTWARE/OS VERSIONS Linux/KDE Plasma: ARTIX LINUX KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 X11 & WAYLAND ADDITIONAL INFORMATION
I'm having more or less the same problem. An already defined connection ends with a "not able to connect" dialog, but a new connection ends at a bluescreen . wlfreerdp & remmina can connect with no issues I'd see this bug as very serious Environment Archlinux , krdc 24.02.0, freerdp 2:2.11.4-1 This is what krdc shows : 1) On an already existing session ``` 10:19:28:059] [14791:14791] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0 [10:19:28:059] [14791:14791] [WARN][com.freerdp.crypto] - CN = sistemasremoto6.******* [10:19:28:366] [14791:14791] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Conexión reinicializada por la máquina remota [10:19:28:366] [14791:14791] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] [10:19:28:796] [14791:14791] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Conexión reinicializada por la máquina remota [10:19:28:796] [14791:14791] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] [10:19:28:797] [14791:14791] [ERROR][com.freerdp.core] - freerdp_post_connect failed KRDC: Unable to connect KRDC: ERRCONNECT_CONNECT_TRANSPORT_FAILED The connection transport layer failed. ``` For a new connection forget about certificate error ... ``` [10:20:19:999] [14791:14791] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0 [10:20:19:999] [14791:14791] [WARN][com.freerdp.crypto] - CN = sistemasremoto2.********* [10:20:19:001] [14791:14791] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [10:20:19:001] [14791:14791] [ERROR][com.freerdp.crypto] - @ WARNING: CERTIFICATE NAME MISMATCH! @ [10:20:19:001] [14791:14791] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [10:20:19:001] [14791:14791] [ERROR][com.freerdp.crypto] - The hostname used for this connection (***.***.***.162:3389) [10:20:19:001] [14791:14791] [ERROR][com.freerdp.crypto] - does not match the name given in the certificate: [10:20:19:001] [14791:14791] [ERROR][com.freerdp.crypto] - Common Name (CN): [10:20:19:001] [14791:14791] [ERROR][com.freerdp.crypto] - sistemasremoto2.***.***.*** [10:20:19:001] [14791:14791] [ERROR][com.freerdp.crypto] - A valid certificate for the wrong name should NOT be trusted! [10:20:38:006] [14791:14791] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_RGBA32 [10:20:38:006] [14791:14791] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32 [10:20:38:017] [14791:14791] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded pulse backend for rdpsnd [10:20:38:018] [14791:14791] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpsnd [10:20:38:018] [14791:14791] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel audin [10:20:38:021] [14791:14791] [INFO][com.freerdp.channels.audin.client] - Loaded pulse backend for audin [10:20:38:021] [14791:14791] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx [10:20:39:247] [14791:14851] [INFO][com.freerdp.channels.rdpsnd.client] - [dynamic] Loaded pulse backend for rdpsnd ```
Duplicate of 481968 and 482836, I'm going to leave this open until 24.02.1 is released next week which contains the fix.
*** Bug 484194 has been marked as a duplicate of this bug. ***
*** Bug 484608 has been marked as a duplicate of this bug. ***
(In reply to Tony Murray from comment #2) > Duplicate of 481968 and 482836, I'm going to leave this open until 24.02.1 > is released next week which contains the fix. Using 24.02.1, I still have the issue. Please let me know if there are additional details that I can provide. Thank you
I am having a similar problem and have spent DAYS debugging what is going on although my situation is slightly different, I think it may point to the root cause. I am running Tumbleweed 20240319 which has krdc 24.02.0-1.1 but I have replicated the problem on a test machine which is running TW 20240328 ( the latest ) and using krdc 24-02.1-1.1. In my case, initially I have no problems using krdc to connect to the xrdp server. BUT, I need to rename the server that is hosting xrdp and after I rename the server from OLD-NAME to NEW-NAME then BOTH krdc 24.02.0-1.1 and krdc 24.02.1-1.1 experience the BLUE screen and do not get the desktop. Although either krdc version has the blue screen problem, I have no problems remotely connecting using xfreerdp or remmina to the NEW-NAME server and ping and ssh also work using the NEW-NAME. Even Windows 10 clients can connect to NEW-NAME with no issues. Generally the other clients display a unknown certificate error but after you accept and continue then your are logged in and the desktop is displayed. If I rename the server back to OLD-NAME then krdc starts working again. If I rename the server back to NEW-NAME then krdc gets the blue screen again and yet EVERYTHING else works fine with NEW-NAME. I even went as far as building a new VM with a fresh TW install and that VM experiences the same issues. On TW, xrdp uses /usr/bin/xrdp-keygen to generate /etc/xrdp/rsakeys.ini which has the key/cert used by the xrdp connections. If you generate your own key/cert and then modify /etc/xrdp/xrdp.ini to set the certificate= and file_key= lines to the generated files and then restart the xrdp service, then all clients work with NEW-NAME ( after accepting the unknown certificate ) except for krdc. For krdc it displays the unknown certificate message ( unlike when using the keys from rsakeys.ini ) but after selecting Continue you are still left with the blue screen. At one point I even heard the login sound play but still no desktop is displayed with krdc. Since everything else works fine with the NEW-NAME for the server EXCEPT for krdc that seems to point to it being the problem. NOTE: I have renamed xrdp servers in the past and have not run into this problem. Hopefully my detailed analysis helps you to identify what is wrong with krdc. Please let me know if you want more details.
* My system: Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-27-generic (64-bit) Graphics Platform: Wayland * KRDC version krdc 4:24.02.2-0xneon+22.04+jammy+release+build29 amd64 * Problem: some times it won't connect to RDP server * Errors: - First server d’abr. 18 11:32:33 hn krdc[20778]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash d’abr. 18 11:36:19 hn krdc[20778]: KRDC: Starting RDP session d’abr. 18 11:36:19 hn plasmashell[20778]: [11:36:19:900] [20778:20778] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0 d’abr. 18 11:36:19 hn plasmashell[20778]: [11:36:19:900] [20778:20778] [WARN][com.freerdp.crypto] - CN = server.domain d’abr. 18 11:36:19 hn plasmashell[20778]: [11:36:19:200] [20778:20778] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Connection reset by peer d’abr. 18 11:36:19 hn plasmashell[20778]: [11:36:19:201] [20778:20778] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] d’abr. 18 11:36:20 hn plasmashell[20778]: [11:36:20:530] [20778:20778] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Connection reset by peer d’abr. 18 11:36:20 hn plasmashell[20778]: [11:36:20:530] [20778:20778] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] d’abr. 18 11:36:20 hn plasmashell[20778]: [11:36:20:530] [20778:20778] [ERROR][com.freerdp.core] - freerdp_post_connect failed d’abr. 18 11:36:20 hn krdc[20778]: KRDC: Unable to connect - second server d’abr. 18 11:36:31 hn krdc[20778]: KRDC: Starting RDP session d’abr. 18 11:36:31 hn plasmashell[20778]: [11:36:31:302] [20778:20778] [ERROR][com.freerdp.core] - transport_connect_tls:freerdp_set_last_error_ex ERRCONNECT_TLS_CONNECT_FAILED [0x00020008] d’abr. 18 11:36:31 hn krdc[20778]: KRDC: Unable to connect * What happens when connecting to those servers via wlfreerdp -First server: $ wlfreerdp /v:server.domain ... Certificate details for server.domain:3389 (RDP-Server): ... The above X.509 certificate could not be verified, possibly because you do not have the CA certificate in your certificate store, or the certificate has expired. Please look at the OpenSSL documentation on how to add a private CA to the store. Do you trust the above certificate? (Y/T/N) y wlfreerdp asks if you want to accept the certificate. KRDC instead of asking, drops the connection. - Second server: $ wlfreerdp /v:server2.domain ... /sec:rdp KRDC now lacks the "advanced options" settings for connecting computers. In older versions, it had and I could connect to this server adding the /sec:rdp in the advanced options settings.
Correction: "Expert options" instead of "advance options" in "Host Configuration" in krdc v23. extraoptions= in file $HOME/.config/krdcrc
I've seen there is the bug 482395 (fixed ) about some of the connection issues. It says is fixed based on merge https://invent.kde.org/network/krdc/-/merge_requests/93 It seems this merge is only intended to resolve RDP proxy and gateway settings, but is not a general solution for all the connection issues. I wonder if it could be possible to bring back the "exta options" settings to solve any kind of RDP issues. In krdc v23 I had some extra settings for some servers that have been lost in krdc v24.
"Disabling All Accelerations" OR "Force RemoteFX" seems to fix the problem for me. It seems H.264 is broken on my machine. Operating System: Manjaro Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-1-MANJARO (64-bit) Graphics Platform: Wayland
This problem just seems to get worse with each update. I have replicated it on a Tumbleweed vm running the latest build 20240507. My KDE Neon test environment updated to the last version just displays the blue screen that everyone else is complaining about. Those are NEW fresh installations that were updated to the latest builds so nothing in the current environment where the problem was originally found comes into play. Trying to connect using krdc 24.02.2 now just core dumps systemd-coredump[758]: [🡕] Process 744 (krdc) of user 1000 dumped core. Stack trace of thread 744: #0 0x00007fee3c013bf1 n/a (libkrdc_rdpplugin.so + 0xebf1) #1 0x00007fee3c01948d n/a (libkrdc_rdpplugin.so + 0x1448d) #2 0x00007fee43ddc245 _ZN15HostPreferences10showDialogEP7QWidget (libkrdccore.so.5 + 0xb245) #3 0x00005619e047d93b n/a (krdc + 0x3293b) #4 0x00005619e0467017 n/a (krdc + 0x1c017) #5 0x00007fee4162a1f0 __libc_start_call_main (libc.so.6 + 0x2a1f0) #6 0x00007fee4162a2b9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a2b9) #7 0x00005619e04672d5 n/a (krdc + 0x1c2d5) Stack trace of thread 745: #0 0x00007fee4170578f __poll (libc.so.6 + 0x10578f) #1 0x00007fee405ce2ff n/a (libglib-2.0.so.0 + 0x5f2ff) #2 0x00007fee405cea0c g_main_context_iteration (libglib-2.0.so.0 + 0x5fa0c) #3 0x00007fee421c0a8c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEve> #4 0x00007fee41f9979b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0> #5 0x00007fee42074cb4 _ZN7QThread4execEv (libQt6Core.so.6 + 0x274cb4) #6 0x00007fee41d7b6fa n/a (libQt6DBus.so.6 + 0x386fa) #7 0x00007fee420ecea9 n/a (libQt6Core.so.6 + 0x2ecea9) #8 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #9 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 747: #0 0x00007fee4168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fee41691d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fee35d10e5b n/a (iris_dri.so + 0x110e5b) #3 0x00007fee35d06e67 n/a (iris_dri.so + 0x106e67) #4 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 746: #0 0x00007fee4170578f __poll (libc.so.6 + 0x10578f) #1 0x00007fee3f6ed8aa n/a (libxcb.so.1 + 0xe8aa) #2 0x00007fee3f6ef41c xcb_wait_for_event (libxcb.so.1 + 0x1041c) #3 0x00007fee3dd34e30 n/a (libQt6XcbQpa.so.6 + 0x5de30) #4 0x00007fee420ecea9 n/a (libQt6Core.so.6 + 0x2ecea9) #5 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 748: #0 0x00007fee4168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fee41691d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40) #2 0x00007fee35d10e5b n/a (iris_dri.so + 0x110e5b) #3 0x00007fee35d06e67 n/a (iris_dri.so + 0x106e67) #4 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #5 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 752: #0 0x00007fee4168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fee41692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065) #2 0x00007fee420f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9> #3 0x00007fee420f3d49 n/a (libQt6Core.so.6 + 0x2f3d49) #4 0x00007fee420ecea9 n/a (libQt6Core.so.6 + 0x2ecea9) #5 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 753: #0 0x00007fee4168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fee41692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065) #2 0x00007fee420f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9> #3 0x00007fee420f3d49 n/a (libQt6Core.so.6 + 0x2f3d49) #4 0x00007fee420ecea9 n/a (libQt6Core.so.6 + 0x2ecea9) #5 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 754: #0 0x00007fee4168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fee41692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065) #2 0x00007fee420f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9> #3 0x00007fee420f3d49 n/a (libQt6Core.so.6 + 0x2f3d49) #4 0x00007fee420ecea9 n/a (libQt6Core.so.6 + 0x2ecea9) #5 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 756: #0 0x00007fee4168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fee41692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065) #2 0x00007fee420f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9> #3 0x00007fee420f3d49 n/a (libQt6Core.so.6 + 0x2f3d49) #4 0x00007fee420ecea9 n/a (libQt6Core.so.6 + 0x2ecea9) #5 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) Stack trace of thread 755: #0 0x00007fee4168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe) #1 0x00007fee41692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065) #2 0x00007fee420f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9> #3 0x00007fee420f3d49 n/a (libQt6Core.so.6 + 0x2f3d49) #4 0x00007fee420ecea9 n/a (libQt6Core.so.6 + 0x2ecea9) #5 0x00007fee41692bb2 start_thread (libc.so.6 + 0x92bb2) #6 0x00007fee4171400c __clone3 (libc.so.6 + 0x11400c) ELF object binary architecture: AMD x86-64 How can you break such critical functionality for users and not make it a priority OR at least rollback the changes until the problem is fixed? My Debian test environment using plasma 5.27.5 and krdc 22.12.3 works fine. My Debian SID test environment using plasma 5.27.10 and krdc 23.08.3 works fine. Something with krdc is SERIOUSLY broken when I can replicate the problems with krdc on different distros. I have been in discussion with the xrdp developers for since March 2024 regarding the problem. In EVERY case where krdc fails with either the blue screen and never displaying the desktop or where krdc core dumps, I can run xfreerdp to make the connection and it works WITHOUT ANY issue. It is my understanding, that krdc is at least partially using freerdp behind the scenes so clearly something in krdc is the source of the problem since xfreerdp works. How can we escalate this so that it such a critical component gets some priority ?
> In EVERY case where krdc fails with either the blue screen and never > displaying the desktop or where krdc core dumps, I can run xfreerdp to make > the connection and it works WITHOUT ANY issue. > > It is my understanding, that krdc is at least partially using freerdp behind > the scenes so clearly something in krdc is the source of the problem since > xfreerdp works. It's not for RDP only, I can't connect to VNC as well (neither AppleVNC nor KRFB) and my bugreport was closed as duplicate of this one. So basically KRDC is unusable for now. > How can we escalate this so that it such a critical component gets some > priority ? Yes it is strange it was broken but has not fixed yet. I'd assume there is no one really maintaining it, or maybe maintainers are busy.
I had to downgrade to krdc-23.08.4 to continue using it because of this same problem. And some weeks ago I had to downgrade to freerdp-2.11.2 too, because OpenSuSE Tumbleweed pushed a new version of freerdp which changes several command line parameters, causing it to be incompatible with krdc 23
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #13) > I had to downgrade to krdc-23.08.4 to continue using it because of this same > problem. And some weeks ago I had to downgrade to freerdp-2.11.2 too, > because OpenSuSE Tumbleweed pushed a new version of freerdp which changes > several command line parameters, causing it to be incompatible with krdc 23 Where did you get the older version of krdc or did you compile yourself ?
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #13) > I had to downgrade to krdc-23.08.4 to continue using it because of this same > problem. And some weeks ago I had to downgrade to freerdp-2.11.2 too, > because OpenSuSE Tumbleweed pushed a new version of freerdp which changes > several command line parameters, causing it to be incompatible with krdc 23 Where did you get krdc 23.08 or did you compile yourself ?
(In reply to Joe S from comment #15) > Where did you get krdc 23.08 or did you compile yourself ? I downloaded them from http://download.opensuse.org/. I still have the URLs. However, I tried opening them and they're a "404-not found error" now. Looks like I was lucky, because those snapshots are removed after some time. Maybe you can get an older version from OpenSuSE Leap. Anyway this chat isn't helping the resolution of this bug. If you want to get older versions you should ask on a forum and not on this bug report.
Broken on openSUSE Tumbleweed 20240524. Thanks to https://bugs.kde.org/show_bug.cgi?id=482950#c10 for the workaround!
(In reply to Tilman Vogel from comment #17) > Broken on openSUSE Tumbleweed 20240524. > Thanks to https://bugs.kde.org/show_bug.cgi?id=482950#c10 for the workaround! Doesn't work for me on TW 20240430 using Accelleration "Disable All Accelleration". Here's the messages for krdc kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_rdpplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_testplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_vncplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed qt.core.qobject.connect: QObject::connect: No such signal KBookmarkManager::changed(QString,QString) KRDC: Starting RDP session [10:35:56:292] [18533:18533] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_RGBA32 [10:35:56:292] [18533:18533] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGR24 [10:35:56:308] [18533:18533] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded pulse backend for rdpsnd [10:35:56:309] [18533:18533] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpsnd [10:35:56:309] [18533:18533] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel audin [10:35:56:318] [18533:18533] [INFO][com.freerdp.channels.audin.client] - Loaded pulse backend for audin [10:35:58:532] [18533:18613] [ERROR][com.freerdp.core.update] - UPDATE_TYPE Bitmap [1] failed [10:35:58:532] [18533:18613] [ERROR][com.freerdp.core.rdp] - DATA_PDU_TYPE_UPDATE - update_recv() failed [10:35:58:532] [18533:18613] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1 [10:35:58:532] [18533:18613] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0 [10:36:00:951] [18533:18533] [ERROR][com.freerdp.core] - freerdp_abort_connect:freerdp_set_last_error_ex ERRCONNECT_CONNECT_CANCELLED [0x0002000B] And then I'm disconnected. Doesn't work for me on TW 20240430 using Accelleration Force RemoteFX. Here's the messages for krdc kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_rdpplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_testplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_vncplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed qt.core.qobject.connect: QObject::connect: No such signal KBookmarkManager::changed(QString,QString) KRDC: Starting RDP session [10:38:17:156] [18740:18740] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_RGBA32 [10:38:17:156] [18740:18740] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32 [10:38:17:175] [18740:18740] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded pulse backend for rdpsnd [10:38:17:176] [18740:18740] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpsnd [10:38:17:176] [18740:18740] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel audin [10:38:17:180] [18740:18740] [INFO][com.freerdp.channels.audin.client] - Loaded pulse backend for audin [10:38:19:330] [18740:18817] [WARN][com.freerdp.channels.rdpdr.client] - Checking ExtendedPDU::RDPDR_USER_LOGGEDON_PDU, client supported, server not found and then it hangs on the Blue Screen. Whereas "xfreerdp -u <user> -v <server> --dynamic-resolution" works fine and displays the desktop. NOTE: I have been trying to resolve these issues for almost 3 MONTHS now. They started for me when TW switched to KDE Plasma 6. The messages above are from my main machine ( where I originally found the problem ) which is running TW 20240430 now, HOWEVER, months ago I setup 2 test machines with brand new TW installations and replicated the problem there on brand new installations completely eliminating any issue with my main machine. Over the last 3 months, I have updated those TW test machines as new builds have become available and then retested but the same basic problem occurs. In ALL cases, where krdc FAILS, I can run xfreerdp and it WORKS without issue. Right now those 2 test TW machines are running TW 20240523. If I run krdc in that test environment ( running 20240523 ) with Disable All Accelleration. Here's the messages for krdc kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_rdpplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_testplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_vncplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed qt.core.qobject.connect: QObject::connect: No such signal KBookmarkManager::changed(QString,QString) Segmentation fault (core dumped) If I run krdc in that test environment ( running 20240523 ) with Force RemoteFX. Here's the messages for krdc kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_rdpplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_testplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_vncplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed qt.core.qobject.connect: QObject::connect: No such signal KBookmarkManager::changed(QString,QString) Segmentation fault (core dumped) So since 20240430 the problem got worse as now I just get a coredump with TW 20240523 Keep in mind those 2 tests machines are BRAND NEW TW installations with NO changes from the default installation other than to install xrdp. And in the test evironment, just like on my main machine using "xfreerdp -u <user> -v <server> --dynamic-resolution" works fine and displays the desktop. Since you said you are using 20240524, I updated the 2 test machines to that version and retested. If I run krdc in that test environment ( running 20240524 ) with Disable All Accelleration. Here's the messages for krdc kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_rdpplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_testplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_vncplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed qt.core.qobject.connect: QObject::connect: No such signal KBookmarkManager::changed(QString,QString) Segmentation fault (core dumped) If I run krdc in that test environment ( running 20240524 ) with Force RemoteFX. Here's the messages for krdc kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_rdpplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_testplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed kf.coreaddons: The plugin "/usr/lib64/qt6/plugins/krdc/libkrdc_vncplugin.so" explicitly states an Id in the embedded metadata, which is different from the one derived from the filename The Id field from the KPlugin object in the metadata should be removed qt.core.qobject.connect: QObject::connect: No such signal KBookmarkManager::changed(QString,QString) Segmentation fault (core dumped) So I still get the coredump with 20240524. And just like all my other tests using xfreerdp WORKS fine and displays the desktop. Generally developers love when a problem is reproducible vs an intermittent problem as it is much easier to figure out what is wrong. Since I have replicated this problem in BRAND NEW TW installations updated over the last few months it seems that I have presented the ideal debugging environment for them to determine the cause and fix the problem.
(In reply to Tilman Vogel from comment #17) > Broken on openSUSE Tumbleweed 20240524. > Thanks to https://bugs.kde.org/show_bug.cgi?id=482950#c10 for the workaround! Some additional details using other linux distros. In all cases I am attempting to connect to the TW 20240524 test machine from the other test machine. Using a Debian 12 ( BookWorm ) test machine which is using plasma 5.27.5 and krdc 22.12.3 to the TW test machine running TW 20240524 WORKS and the desktop is displayed. Using a Debian SID ( Trixie ) test machine which is using plasma 5.27.10 and krdc 23.08.3 to the TW test machine running TW 20240524 WORKS and the desktop is displayed. After updating Debian SID test machine to latest version which is using plasma 5.27.11 and krdc 23.08.3 I retested to the TW test machine running TW 20240524 WORKS and the desktop is displayed. Using a EndeavourOS test machine which is using plasma 6.0.5 and krdc 24.05.0 to the TW test machine running TW 20240524 FAILS and just displays the BLUE screen but displayed the following messages KRDC: Starting RDP session [12:45:38:623] [1674:1674] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_RGBA32 [12:45:38:623] [1674:1674] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32 [12:45:38:625] [1674:1674] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded pulse backend for rdpsnd [12:45:38:625] [1674:1674] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpsnd [12:45:38:625] [1674:1674] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel audin [12:45:38:626] [1674:1674] [INFO][com.freerdp.channels.audin.client] - Loaded pulse backend for audin [12:45:38:626] [1674:1674] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx Using a Manjaro test machine which is using plasma 6.0.5 and krdc 24.0.5.0 to the TW test machine running TW 20240524 FAILS and coredumps Using a openSUSE MicroOS KDE test machine which is using plasma 6.0.4 and krdc 24.02.2 to the TW test machine running TW 20240524 FAILS and coredumps. Using a Ubuntu 23.10 test machine which is using plasma 5.27.8 and krdc 23.08.1 to the TW test machine running TW 20240524 WORKS and the desktop is displayed. Using a Windows 11 test machine and the Microsoft Remote Desktop client to the TW test machine running TW 20240524 WORKS and the desktop is displayed. So in summary, these tests show that The problem is occurs with other Linux distros that are using plasma 6 and krdc 24.* The problem does NOT occur with other Linux distros that are still using plasma 5 and krdc 23.* Even the Windows 11 RDP client WORKS I'm not sure what other information the developers could possibly need to get this problem addressed.
If you use openSUSE Tubleweed, you can either 1. Install older KRDC (krdc5 — 23.08.4) from this repo: https://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/Frameworks5/openSUSE_Tumbleweed/ Which could be installed simultaneously with KRDC based on KF6. OR 2. Install develompent version from https://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_Factory/ But in my experience this version has problems with mouse input with scaling or multiple screens (not sure) on wayland session at least.
I get blue screen too. Solved by disabling acceleration, but the performance is not exciting. I also have the problem, already reported by another user, of the impossibility of using the 'domain\user' form considering that I connect to a remote computer in a domain. Greetings
(In reply to Mykola Krachkovsky from comment #21) > If you use openSUSE Tubleweed, you can either > 1. Install older KRDC (krdc5 — 23.08.4) from this repo: > https://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/ > Frameworks5/openSUSE_Tumbleweed/ > Which could be installed simultaneously with KRDC based on KF6. > OR > 2. Install develompent version from > https://download.opensuse.org/repositories/KDE:/Unstable:/Applications/ > KDE_Unstable_Frameworks_openSUSE_Factory/ > But in my experience this version has problems with mouse input with scaling > or multiple screens (not sure) on wayland session at least. Thanks for providing those options. I missed getting krdc 23.* version from the TW history repos before it was gone and was not aware of those.
Can confirm this on a fully up-to-date Fedora 40 KDE Spin. KRDC 24.05.2. Rdesktop also connects non-accelerated, remmina works.
FYI, this bug is useless. Many different kinds of failures will result in a "blue screen" Perhaps the real bug is badly raised errors.
Trying to sum this up: Krdc < 24 internally runs a copy of xfreerdp, so as log as xfreerdp works, krdc works too. Since version 24 krdc uses the libfreerdp library directly. If you were not able to connect or you get disconnected immediately / after some time: initial libfreerdp support was barebone and a few bugs causing disconnections were found and fixed in the following versions. We are still working out such bugs, eg. v24.12 will fix a disconnection bug on touchpad scroll. If you are ale to connect but get a black/blue screen or screen artifacts (on wayland): this is caused by a wrong/mismatched acceleration or security setting. Regarding acceleration, avoid H.264 and try to use RemoteFX or disable acceleration and it should work. Regarding security, automatic negotiation has seen fixes and should be working now. We already implemented an option to manually set the security method and it will be released in a future version. I'm closing this bug since it became a mess of different reports related to different bugs. Some of them have already been fixed as of v24.08.3 / v24.12, so I encourage everyone to try again using one of these versions and open a new bug if you are still experiencing problems. Thank you for your patience.