Bug 485215 - KRDC hangs when trying to connect to VNC host
Summary: KRDC hangs when trying to connect to VNC host
Status: RESOLVED DUPLICATE of bug 486178
Alias: None
Product: krdc
Classification: Applications
Component: VNC (show other bugs)
Version: 24.02.1
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Urs Wolfer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-04-08 07:01 UTC by Stefan Becker
Modified: 2024-05-01 09:24 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Becker 2024-04-08 07:01:27 UTC
SUMMARY

I just upgraded from Fedora 39 to 40, i.e. I moved from KDE Plasma 5 to Plasma 6. KRDC connections using VNC plugin stopped working: KRDC hangs before even trying to create a network connection.

STEPS TO REPRODUCE
1. start connection to host using vnc protocol

OBSERVED RESULT

Nothing: krdc application stops responding. E.g. disconnect or close window leads to "krdc application does not respond" dialog.

According to networking status krdc hangs before even trying to create a network connection. I.e. this problem can even be reproduced by trying to connect to a non-existing VNC host.

EXPECTED RESULT

Connection to VNC host succeeds.

SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 40
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.2-300.fc40.x86_64 (64-bit)
Graphics Platform: Wayland

ADDITIONAL INFORMATION

* I tried on two different systems: same result
* I used tigervnc client to connect to VNC host: works fine
* I tried "krdc --platform xcb": no result
* I deleted all KRDC configurations from my home directory and then tried to create a new connection: same result (i.e. not caused by old Plasma 5 settings)
* I enabled TEST plugin and created a connection using "test:" protocol: works fine, i.e. I get a window with yellow background (I guess that is what the test plugin generates). I can successfully disconnect from this connection
* (I don't have a RDP host available for real testing, sorry) I created a RDP connection to a non-existing host: KRDC tries to connect to the host and returns after a short while "can't connect to host", i.e. it seems that RDP plugin works fine.

When I run "krdc" from the konsole the only messages I get are these at startup:

~~~
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
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_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
qt.core.qobject.connect: QObject::connect: No such signal KBookmarkManager::changed(QString,QString)
~~~

There are no additional messages when I try to create the VNC connection
Comment 1 Stefan Becker 2024-04-08 11:28:23 UTC
Just found a RDP host @ work. Connection with krdc works, it checks the certificate and then asks to username & password (I have no login there). So I assume that the RDP plugin is fully working and only the VNC plugin is broken.
Comment 2 foxfire-auspex 2024-04-29 12:21:37 UTC
(In reply to Stefan Becker from comment #1)
> Just found a RDP host @ work. Connection with krdc works, it checks the
> certificate and then asks to username & password (I have no login there). So
> I assume that the RDP plugin is fully working and only the VNC plugin is
> broken.

I'm not sure that I've encountered the exact same bug, but they're superficially similar enough that I'll just add my information here.

Since upgrading to Fedora 40, KRDC does no longer connect to a Windows VM I use at work via RDP. Since Remmina shows no such issue, I assume that my experience may be related to this bug.

I run the following versions:
Operating System: Fedora Linux 40
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.7-300.fc40.x86_64 (64-bit)
Graphics Platform: Wayland

krdc & krdc-libs: 24.02.2-1.fc40

If I run krdc in a terminal, I get the following output (which is new since Fedora 40, the host I'm trying to connect to has not changed in any meaningful way):
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
[13:52:25:888] [18828:18828] [WARN][com.freerdp.crypto] - Certificate verification failure 'self-signed certificate (18)' at stack position 0
[13:52:25:888] [18828:18828] [WARN][com.freerdp.crypto] - CN = [censored]
[13:52:39:629] [18828:18828] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Connection reset by peer
[13:52:39:629] [18828:18828] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[13:52:40:958] [18828:18828] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Connection reset by peer
[13:52:40:958] [18828:18828] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[13:52:40:958] [18828:18828] [ERROR][com.freerdp.core] - freerdp_post_connect failed
KRDC: Unable to connect
Comment 3 Stefan Becker 2024-04-29 12:34:44 UTC
(In reply to foxfire-auspex from comment #2)
> 
> I'm not sure that I've encountered the exact same bug, but they're
> superficially similar enough that I'll just add my information here.

Your bug is not a bug, I fear. The log clearly shows that FreeRDP crypto rejects the self-signed certificate offered by the RDP host. After that the connection is closed. KRDC does *NOT* freeze up as it does with VNC connections.

> KRDC: Starting RDP session
> [13:52:25:888] [18828:18828] [WARN][com.freerdp.crypto] - Certificate
> verification failure 'self-signed certificate (18)' at stack position 0
> [13:52:25:888] [18828:18828] [WARN][com.freerdp.crypto] - CN =
> [censored]

I'm not sure if KRDC/FreeRDP has an option/dialog to ignore certificate errors. There may also have been a tightening of system TLS security settings in Fedora 40 (there have been several rounds of that in the last releases), which you would need to loosen to be able to connect.
Comment 4 foxfire-auspex 2024-04-29 12:43:10 UTC
(In reply to Stefan Becker from comment #3)
> I'm not sure if KRDC/FreeRDP has an option/dialog to ignore certificate
> errors. There may also have been a tightening of system TLS security
> settings in Fedora 40 (there have been several rounds of that in the last
> releases), which you would need to loosen to be able to connect.

Thank you very much for the input. It's somewhat embarrassing that this wasn't obvious to me. I'll investigate further on my own then.
Comment 5 Fabio 2024-04-30 23:05:12 UTC
The original issue is possibly a duplicate of BUG 486178
Comment 6 Stefan Becker 2024-05-01 09:24:27 UTC
Yeah, that looks like the same issue.

*** This bug has been marked as a duplicate of bug 486178 ***