Closed JoeSalmeri closed 3 months ago
matt335672
commented
7 months ago Run krdc from the command line. It may display some useful error messages.
You're almost certainly correct that this is a krdc TLS caching issue. You can check this by asking the client to connect using RDP security rather than TLS. I don't know how you would go about this I'm afraid.
matt335672
commented
7 months ago 
JoeSalmeri
commented
7 months ago @matt335672
Thanks Matt, I was hoping you'd reply and agree with my analysis.
I had tried running from the command line and I "think" these messages are probably talking about the stored TLS cached item but I have been unable to find it and google searches ( all day ) have not been helpful
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
I will look into how to use RDP security instead of TLS but krdc doesn't seem to have any options for that which I have found so far.
Thanks for that link, it basically talks about using your browser to view modify the certificates which I had looked at but that does not seem to show the certificates in question and in my case there are only 2 certificates one of which is for an internal website and the other seems unrelated to rdp.
I don't understand why krdc is not prompting about the certificate change like Windows RDP does.
Even if it didn't prompt it would be easy to fix on Windows as Id just run the certificate tool there and delete it but I have not seen anything like that for Windows.
It seems pretty clear to me though that it is definitely a certificate issue because everything else works with the new name and if you rename the server back then using krdc to the old name now works.
What's driving me crazy is that I replaced the main RDP server last year with a new server ( using the original name ) and I renamed the old server to *-OLD and I can RDP into that without issue.
In fact this all started with me renaming the *-OLD server to a new name which is when the issue started, however, as I mentioned I recreated the same situation by creating a VM, installing rdp there ( and it working ) and then renaming the hostname for the vm and hitting the same issue ( which is also fixed by renaming it back ).
Any other ideas are MOST appreciated.
matt335672
commented
7 months ago You can use strace to see what files krdc is accessing:-
strace -e trace=%file <krdc command>That might give you some clues as to where the cert store is, so you can delete it.
JoeSalmeri
commented
7 months ago @matt335672
Thanks I just tried that.
I would "expect" that this certificate would be stored somewhere in the user home directory tree, however, I just did a test for a new user so that there would be no user config for krdc at all and that user had the same issue.
Going through the strace ( HUGE ) and coming up with a list of unique file names ignoring fonts, icons, *.so references, etc, the list is narrowed down to the following but I reviewed each of the files and don't see anything.
/etc/crypto-policies/back-ends/gnutls.config /etc/crypto-policies/back-ends/opensslcnf.config /etc/pulse/client.conf /etc/ssl/openssl.cnf /etc/xdg/kdeglobals /etc/xdg/kwinrc /home/joe/.cache/mesa_shader_cache/index /home/joe/.config/kcminputrc /home/joe/.config/kdedefaults/kcminputrc /home/joe/.config/kdedefaults/kdeglobals /home/joe/.config/kdedefaults/kwinrc /home/joe/.config/kdeglobals /home/joe/.config/krdcrc /home/joe/.config/kwalletrc /home/joe/.config/kwinrc /home/joe/.config/session/krdc_1024420a1d31ff000171165212800000022140074_1711652128_584323 ? /home/joe/.local/share/krdc/bookmarks.xml /home/joe/.local/share/krdc/krdcstaterc ? /usr/share/drirc.d/00-mesa-defaults.conf /usr/share/drirc.d/00-radv-defaults.conf /usr/share/hwdata/pnp.ids /usr/share/locale/locale.alias /usr/share/qt6/translations/qt_en.qm /usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE /usr/share/X11/locale/locale.alias /usr/share/X11/locale/locale.dir /var/lib/dbus/machine-id
I also thought possibly it had to do with the /etc/xrdp/raskeys.ini file and that the keys generated could have the hostname in the data ( certificates I generated for web server do ) so I ran xrdp-keygen again to recreate it and rebooted but still no luck.
The search continues......
JoeSalmeri
commented
7 months ago @matt335672
Ok, to eliminate ANYTHING on the client machine, I built a brand new Tumbleweed VM and installed krdc and freerdp and then tried to connect from that VM to the xrdp server using the hostname the rdp server was renamed to.
Since this is a brand in install and it never connected to the RDP server before it cannot have anything cached or prior settings anywhere on the entire VM.
Using the renamed ( new ) hostname for the RDP server:
krdc does not work, just displays the blue screen and no login prompt for xvnc freerdp works fine, xvnc login displayed, I can login and desktop is displayed
As I mentioned earlier, I believe freerdp by default ignores cert errors so that would explain why it works.
Since this failing when I use a brand new built client machine, that means that whatever is causing the issue is on the RDP server and not the client side, but I still don't think this has anything to do with xrdp since it works fine with freerdp.
I suspect what is happening is that that when a client tries to connect using the NEWname, the server is responding with a certificate with the OLD name which causes a certificate mismatch error and that is why krdc is failing.
They questions what is that certificate ???
matt335672
commented
7 months ago That's some useful detective work you've done there, @JoeSalmeri
I was thinking about this after your last (also informative) post. I'm wondering if krdc is wanting an exact hostname match from the presented certificate.
You can examine the certificate xrdp is presenting to the client(s) with openssl x509.
First, have a look in /etc/xrdp/xrdp.ini and see where certificate= is pointing. If there's nothing here, the default is probably /etc/xrdp/cert.pem. I say 'probably' as there's something at the back of my head telling me that SuSE does something weird with /etc but I could be wrong.
Here's an example from my development machine:-
$ sudo cat /etc/xrdp/cert.pem | openssl x509 -text -noout | head -20
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
4a:31:4b:19:d2:ec:ae:01:bf:f3:49:88:53:0a:fa:34:6a:3a:d4:3f
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = CA, L = Sunnyvale, O = xrdp, CN = www.xrdp.org
Validity
Not Before: Nov 5 17:24:32 2022 GMT
Not After : Nov 5 17:24:32 2023 GMT
Subject: C = US, ST = CA, L = Sunnyvale, O = xrdp, CN = www.xrdp.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a3:43:b3:bb:f5:08:54:b4:da:b3:a4:57:b3:0b:
a3:22:9b:1d:e4:fa:d1:cf:96:48:7b:92:77:1b:37:
37:bf:92:e8:52:a8:b9:bd:78:93:0c:d6:c5:5b:0b:
55:ba:56:16:2d:2b:37:cb:b5:02:63:a0:8b:05:69:
45:d9:f9:e0:d3:10:b9:35:a3:eb:d5:50:96:36:be:
The hostname is in the CN field of the subject (above is www.xrdp.org). The same name appears in the Issuer, which tells us this is a self-signed certificate.
Have a look at yours. If necessary we can reconstruct these to match your new hostname.
One other thing - some platforms soft-link the certificate to some global location. Debian does this, and SuSE may be similar.
JoeSalmeri
commented
7 months ago @matt335672
Thanks, I agree with you completely ( but you did a better job of stating what I was trying to say ).
On Windows when the rdp host name changes like this you get the certificate prompt on the client. On Linux, you don't get the prompt just the blue screen.
xfreerdp has a cmd line option to ignore certificate errors ( which I believe it was compiled as the default ) which is why it works.
After building that new client machine and getting the same error I posted my msg to you but after pondering for a while I came to the conclusion that although it proved that there was nothing from the client config that could be causing the issue it did not completely eliminate the client from being the source of the problem, however, since it was a new machine the only thing left is that certificate that is used by xrdp.
We know that the certificate doesn't match because Windows rdp clients get the prompt.
I looked at the /etc/xrdp/xrdp.ini but the cerificate= line is blank.
When you install xrdp it runs /usr/bin/xrdp-keygen which creates /etc/xrdp/rsakeys.ini which I believe to be the keys that it is using, however, it is not a pem file and therefore I'm not sure how to decipher it.
While it would probably be a bad idea :-) to post the public and private security keys, since I have a throw away test environment where I duplicated the problem so not really an issue as once this is resolved I'll be getting rid of the test machines.
Here is the /etc/xrdp/rsakeys.ini file from the rdp server that was renamed.
[keys] pub_exp=0x01,0x00,0x01,0x00 pub_mod=0x5d,0x21,0x47,0x69,0x0a,0x38,0x12,0x60,0x2a,0x5d,0xa7,0x99,0xa5,0xad,0xf8,0x9d,0x5f,0x33,0xf6,0x42,0x94,0xfb,0xc7,0x9e,0x99,0x8a,0x31,0xcd,0x4c,0xfd,0xc9,0x09,0x0c,0x43,0x20,0xcc,0x0f,0x10,0xcf,0x3c,0x86,0x76,0xfc,0x67,0x34,0xd2,0x7f,0xa8,0xab,0x7c,0xe9,0x1d,0xad,0xac,0x31,0x37,0xca,0x34,0xb9,0x48,0x12,0xc9,0x49,0x71,0x55,0x05,0xb6,0x1a,0xc0,0x4b,0x97,0x2f,0xe7,0x5e,0x94,0x69,0xeb,0x1e,0x83,0xc4,0x6a,0xe8,0x96,0x93,0x44,0xe9,0x47,0x49,0x14,0x14,0xc4,0x7f,0xfb,0x0f,0x05,0xb1,0x13,0x55,0x9b,0xb4,0x2c,0xc6,0x00,0x94,0x2a,0xf7,0xee,0x10,0x91,0x90,0x80,0x1e,0x54,0x2b,0x9e,0x8e,0x86,0xde,0x69,0xee,0x03,0xd4,0x08,0xa0,0xa2,0xc1,0xce,0xb5,0xf7,0x03,0x52,0x77,0x99,0x19,0xd5,0x08,0xd3,0x0a,0x66,0xd4,0xb5,0xfe,0x5b,0x8d,0x57,0xdb,0xbf,0x4e,0x5c,0x0c,0x5f,0x24,0xa8,0x5b,0xca,0xb1,0x75,0x70,0x77,0xfd,0xe9,0xcd,0x62,0xe9,0x3e,0xae,0x07,0xfd,0xb3,0xb9,0xd9,0x9f,0xaa,0xc8,0xac,0xb6,0xd0,0xb1,0xaa,0x78,0x4b,0x74,0x17,0x7f,0xaf,0xdc,0xb9,0xa9,0x35,0xf3,0x06,0x51,0x68,0x69,0x41,0xdb,0x04,0xc7,0x4f,0xdf,0x38,0x26,0x6d,0x21,0x27,0xb6,0x3b,0xa8,0x67,0xbf,0xae,0x59,0x1c,0x0b,0x4f,0x83,0x74,0x9a,0xb2,0x41,0xd9,0x39,0x0f,0xbf,0x0e,0xda,0x55,0x33,0x3c,0x65,0x18,0xcf,0xc1,0xf0,0xa3,0x5c,0xcd,0xec,0x97,0xe2,0xdc,0xba,0xfe,0x64,0xf5,0x4b,0xd3,0x15,0xd8,0xd3,0x1f,0xbb,0x67,0x0b,0xe1,0x95 pub_sig=0xb4,0x84,0xc1,0xbe,0x86,0x00,0x30,0x9a,0x6d,0x92,0xc9,0x19,0xd5,0x8e,0x03,0xd6,0x78,0x5d,0x21,0x3b,0x3d,0x77,0xe6,0x7a,0x65,0x1c,0xf2,0xd7,0x3a,0x5b,0xc2,0xe6,0xca,0x5f,0xad,0x38,0xa3,0x9d,0xd1,0x6f,0x28,0x9a,0x5e,0xdd,0x26,0x0f,0xfa,0xdd,0x43,0x89,0xb7,0xe2,0x19,0x97,0xc4,0x91,0x52,0xc0,0x9e,0x63,0xb4,0xd9,0x69,0x5e pri_exp=0xb1,0x72,0x22,0x7f,0x7a,0x9e,0x89,0x30,0x9b,0x9f,0x9b,0xf9,0xb7,0x0c,0xac,0x36,0xe3,0xb3,0xaf,0xbb,0x80,0x9b,0x89,0x30,0xf1,0x3e,0x81,0x63,0x63,0xd1,0xfa,0x81,0xe1,0x48,0xe3,0x54,0xcf,0xa0,0xa6,0xc9,0x75,0x4f,0x0a,0x77,0xe0,0x59,0x9a,0x85,0x2d,0xaf,0x64,0x33,0x63,0x99,0x87,0x10,0x01,0x7d,0x98,0x92,0xb9,0x80,0xf8,0x18,0xb3,0x20,0x83,0x0e,0x24,0x74,0x26,0x03,0x00,0x9b,0x48,0x7d,0x0f,0xf1,0x31,0x2d,0x6b,0x3a,0xa7,0x1b,0xf9,0x99,0x5b,0xa5,0xc9,0x5f,0x72,0xda,0xf6,0xdb,0xf6,0x83,0x8a,0x5f,0x82,0xf5,0x93,0xd2,0xa3,0x93,0xcf,0x66,0xa4,0x2e,0x85,0xc5,0x8f,0xb9,0xab,0x1b,0x14,0xac,0x12,0xf1,0x1f,0xba,0x05,0x54,0x1f,0x11,0x54,0x69,0x7c,0xc7,0x16,0xe9,0xc5,0x7a,0xaf,0x22,0xd8,0xbf,0xfb,0x30,0xba,0xc6,0xce,0xbe,0xf5,0x6e,0xfc,0xd0,0xdb,0xce,0x17,0x0a,0xe0,0x44,0xa0,0xd4,0xc6,0x4a,0x01,0x63,0xa4,0x07,0x1f,0x9d,0xe2,0x6e,0xa5,0xe9,0xe0,0xb7,0xf5,0x94,0x9b,0xcc,0xc1,0xbf,0x17,0x54,0xef,0x03,0xc3,0x6d,0xa5,0x09,0xc1,0x58,0x14,0xe7,0x3c,0x29,0x82,0x55,0x26,0x85,0x79,0xcf,0x41,0x8c,0x2a,0xfb,0x37,0x5c,0xb0,0xd3,0xa8,0xd6,0x84,0x94,0xc6,0xa6,0xd5,0x9d,0x89,0x83,0xc9,0x9c,0xaa,0x8f,0x30,0x6b,0x5c,0x3d,0xcf,0xf2,0x6b,0xc3,0xf4,0x9b,0xb7,0xb5,0x9b,0xae,0xa7,0xa1,0xbd,0x10,0xc4,0xf3,0xe5,0xae,0x0f,0xf2,0xb9,0x1d,0xeb,0x77,0xcb,0x6f,0x42,0xcc,0x2d,0x25,0x24,0xa1,0xde,0x95,0x1c,0x0b
Note that there are 5 lines in that file that look like this followed by the hex bytes that are the certificate
[keys] pub_exp= pub_mod= pub_sig= pri_exp=
Any idea how to convert that to something that I can decipher like you did with the pem and openssl ?
I expect that if we can do that it is going to show the OLD sever name and not the NEW one.
I'll bet there is a bug in xrdp-keygen that is somehow using the OLD server name which is why a reinstall of xrdp after renaming and rebooting server still doesn't work.
I'd love to prove that though so I can submit a bug report to TW.
FYI, TW has /etc/ssl/certs as a symlink to ../../var/lib/ca-certificates.pem and you can run update-ca-certificates but I already tried that after running xrdp-keygen with no luck.
You did give me an idea though.
In the xrdp.ini file it has this comment
; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365
I ran by used xrdp.private.pem and xrdp.public.pem and then updated xrdp.ini to
certificate=/etc/xrdp/xrdp.public.pem key_file=/etc/xrdp/xrdp.private.pem
Then I rebooted the server instead of just restarting xrdp to be sure everything started clean.
If I then attempt to connect from a client, now I get a unknown certificate prompt.
There I can click details and it does show that CN= the new server name for COMMON Name: as well as for the 2 places that have CN=.
Clicking continue ( but didn't check Remember this certificate ) displays the blue screen but it seems to flash like it was trying to display the desktop. The "flash" doesn't happen every time.
I have duplicated these results from multiple clients Linux clients.
On Windows, I get the same unknown certificate prompt, however, after continuing the Linux desktop is displayed.
So that leads me to believe that there is some kind of bug in krdc.
Tumbleweed uses /usr/bin/xrdp-keygen to generate the key pairs that it uses, but it stores them in /etc/xrdp/rsakey.ini
matt335672
commented
7 months ago Here are a few pointers:-
1) certificate= is often blank. The default is cert.pem in the same directory
2) rsakeys.ini is nothing to do with TLS. It's used if you wind the security setting back to RDP. If you use TLS security, this file is unused.
3) If the client detects a TLS failure, the client should really terminate the connection. Since that isn't happening, the problem may lie elsewhere.
A question for you - are you passing a password over the link to log in without displaying the login prompt? If so, can you try without the password.
JoeSalmeri
commented
7 months ago @matt335672
Sorry I know that was a lot to digest.
Here's quick summary:
Everything works fine until I rename the server.
After that everything works using the NEW-NAME EXCEPT for krdc.
Generally clients get the certificate warning and after it is accepted they get the desktop.
krdc just gets the blue screen ( after server is renamed, before the server renamed krdc works fine )
Based on your earlier reply I generated a key/cert pair and modified xrdp.ini to use them.
After restarting xrdp I get the same results as above where everything works EXCEPT krdc.
The one difference is that krdc displays a certificate warning now that xrdp is configured with
the key/cert files, however, unlike the other clients, after you accept the certificate krdc
still just displays the blue screena and no desktop.
Regarding your pointers ( THANKS )
I use the TW default config for xrdp and TW generates /etc/xrdp/rsakeys.ini when xrdp pkg is installed
TW sets security to negotiate but there are no key/cert files configured and the default pem files don't exist so
I would expect negotiate to default to RDP since it has no key/cert files to use and therefore would
be using rsakeys.ini.
Right, the connection doesn't get terminated with krdc it just displays the blue screen and
you never get the desktop. I have even heard the login sound played.
Since other rdp clients work ( using rsakeys.ini OR the key/cert files ) it seems pretty clear
that krdc is what is broke.
Regarding your question, I have tried both with and without the password.
When using krdc it doesn't matter, all you get is the blue screen even when you don't send the
password.Let's find out if this is a problem with TLS, or whether it's something else.
Are you in an environment where you can saely set security_layer=rdp in xrdp.ini? After that, either krdc works (which means it's probably an issue with TLS somehow), or it doesn't work in which case we can dig further.
JoeSalmeri
commented
7 months ago @matt335672
Let's find out if this is a problem with TLS, or whether it's something else.
Are you in an environment where you can saely set
security_layer=rdpin xrdp.ini? After that, either krdc works (which means it's probably an issue with TLS somehow), or it doesn't work in which case we can dig further.
Hi Matt,
Sorry for the long delay we had a health issue in the family.
Yes, I can test that using the test environment I setup using 2 kvm VMs both running Tumbleweed 20240409 which is using krdc 24.02-1-1.2 and xfreerdp 3.4.0-1.1.
After changing xrdp.ini security_layer=rdp and rebooting the xrdp server ( I know I could just restart the service but I want to make sure nothing from a previous test causes an issue ):
Using krdc 24.02-1-1.2 on the client kvm to connect to the xrdp server kvm displays the blue screen and no prompt for the password or ever displaying the desktop.
Using xfreerdp 3.4.0-1.1 on the client kvm to connect to the xrdp server kvm prompts for the domain and then the user password and then the desktop is displayed.
So client pc is the same kvm vm connecting to the same server kvm vm running xrdp and the only difference is whether the client pc is using krdc ( which displays blue screen ) vs xfreerdp ( which works and displays desktop ).
If I change xrdp.ini back to security_layer=negotiate and reboot the kvm xrdp server then I get the exact same results as security_layer=rdp was used.
Something else I found interesting.
I dug up a backup of a kvm vm that still has plasma 5 installed and has krdc 23.08.4-1.2 installed
If I test using the plasma 5 client ( and xrdp.ini security_layer=negotiate ) then it displays the blue screen and password prompt and then the desktop is displayed.
One ODD thing using the plasma 5 client is that whatever resolution I specify in krdc seems to limit the rdp session to that resolution. I can change the resolution in the rdp session after connecting BUT that doesn't change the size of what is viewable in the rdp session. Instead it stays stuck at the original size that krdc started the session with. That makes it difficult to work since you can only see part of the screen ( so I could not even logoff because start button was on the part of the screen you can no longer see. Increasing the rdp session window has no effect, the viewable area is still the original size but the resolution in the session is the larger changed too size.
I'm sure that is a totally separate issue.
Also interesting is that if I use xfreerdp from the plasma5 client then the ODD resolution issue does NOT occur.
In all of my testing it seems pretty clear that krdc 24 is clearly broken as other clients work.
I'm happy to do any other testing if you need me too.
JoeSalmeri
commented
7 months ago @matt335672
FYI, I just updated the 2 kvm plasma 6 test machines to TW 20240412. It still has the same krdc and xfreerdp versions.
Basically same results, krdc blue screen and no password prompt or desktop, xfreerdp works fine.
At least it is consistently broken....
matt335672
commented
7 months ago Well it's not TLS then - nice testing.
Can you post the end of the xrdp.log file after connecting to a broken session? We can see if it's connecting to something, or connecting to nothing at all.
JoeSalmeri
commented
7 months ago On 4/15/24 3:37 PM, matt335672 wrote:
Well it's not TLS then - nice testing.
Can you post the end of the xrdp.log file after connecting to a broken session? We can see if it's connecting to something, or connecting to nothing at all.
To make it easy I shutdown the xrdp service and renamed xrdp.log and xrdp-sesman.log and then restarted the xrdp service.
At that point both logs are 0 bytes.
Then I tried connecting using krdc from the TW latest kvm client, which displays blue screen, no pswd prompt, and no desktop.
xrdp.log contains the following:
[20240415-15:53:53] [ERROR] Cannot read certificate file /etc/xrdp/cert.pem: No such file or directory [20240415-15:53:54] [ERROR] Cannot read private key file /etc/xrdp/key.pem: No such file or directory [20240415-15:53:55] [ERROR] dynamic_monitor_open_response: error [20240415-15:53:55] [ERROR] xrdp_rdp_recv: xrdp_channel_process failed
The cert.pem and key.pem errors make sense since xrdp.ini is set to negotiate and those files don't exist.
Seems the source of the problem are the other 2 errors
xrdp-sesman.log is still empty / 0 bytes
I then hit disconnect in krdc client which wrote the following 2 items to xrdp.log
[20240415-15:54:25] [ERROR] xrdp_iso_send: trans_write_copy_s failed [20240415-15:54:25] [ERROR] Sending [ITU T.125] DisconnectProviderUltimatum failed
Then I ran xfreerdp from the TW latest client and entered the pswd.
It fails with the following but I believe that when krdc attempts to connect it leaves things in some sort of inconsistent state. I say that because the systemd --user process is still there for the user that attempted to connect via RDP using krdc and there is a xrdp-chansrv process too ( which I'm guessing is screwed up because of the problem and which causes xfreerdp to fail when it would normally work )
[15:56:25:96] [2505:000009cc] [INFO][com.winpr.timezone] - [winpr_detect_windows_time_zone]: tzid: America/New_York [15:56:25:111] [2505:000009cc] [WARN][com.freerdp.core.connection] - [rdp_client_connect_auto_detect]: messageChannelId == 0 [15:56:25:113] [2505:000009cc] [ERROR][com.freerdp.core.license] - [license_read_binary_blob_data]: license binary blob::type expected BB_UNKNOWN, got BB_ERROR_BLOB [15:56:25:113] [2505:000009cc] [WARN][com.freerdp.core.license] - [license_read_binary_blob_data]: license binary blob::type BB_ERROR_BLOB, length=0, skipping. [15:56:25:113] [2505:000009cc] [WARN][com.freerdp.core.connection] - [rdp_client_connect_auto_detect]: messageChannelId == 0 [15:56:25:169] [2505:000009cc] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Local framebuffer format PIXEL_FORMAT_BGRX32 [15:56:25:170] [2505:000009cc] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Remote framebuffer format PIXEL_FORMAT_BGRA32 [15:56:25:210] [2505:000009cc] [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [static] Loaded fake backend for rdpsnd [15:56:25:211] [2505:000009cc] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel ainput [15:56:25:211] [2505:000009cc] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpgfx [15:56:25:211] [2505:000009cc] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel disp [15:56:25:211] [2505:000009cc] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpsnd [15:56:27:404] [2505:000009e0] [WARN][com.freerdp.channels.drdynvc.client] -
OnOpen=(nil), OnClose=0x7f7d646fa5c0 [15:56:28:448] [2505:000009cc] [INFO][com.freerdp.core] - [rdp_print_errinfo]: ERRINFO_LOGOFF_BY_USER (0x0000000C):The disconnection was initiated by the user logging off their session on the server. [15:56:28:448] [2505:000009cc] [ERROR][com.freerdp.core] - [rdp_set_error_info]: ERRINFO_LOGOFF_BY_USER [0x0001000C] [15:56:28:450] [2505:000009e0] [WARN][com.freerdp.channels.drdynvc.client] -
OnOpen=(nil), OnClose=0x7f7d646fa5c0
If I reboot the RDP server ( and erased the logs from the previous test ) and then use xfreerdp ( without trying krdc first ) then, I get the pswd prompt, and then the desktop displays.
I ran xfreerdp from the cmd line and it displays the following messages
[16:07:13:825] [2614:00000a37] [INFO][com.winpr.timezone] - [winpr_detect_windows_time_zone]: tzid: America/New_York [16:07:13:828] [2614:00000a37] [WARN][com.freerdp.core.connection] - [rdp_client_connect_auto_detect]: messageChannelId == 0 [16:07:13:829] [2614:00000a37] [ERROR][com.freerdp.core.license] - [license_read_binary_blob_data]: license binary blob::type expected BB_UNKNOWN, got BB_ERROR_BLOB [16:07:13:829] [2614:00000a37] [WARN][com.freerdp.core.license] - [license_read_binary_blob_data]: license binary blob::type BB_ERROR_BLOB, length=0, skipping. [16:07:13:829] [2614:00000a37] [WARN][com.freerdp.core.connection] - [rdp_client_connect_auto_detect]: messageChannelId == 0 [16:07:13:837] [2614:00000a37] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Local framebuffer format PIXEL_FORMAT_BGRX32 [16:07:13:837] [2614:00000a37] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Remote framebuffer format PIXEL_FORMAT_BGRA32 [16:07:13:869] [2614:00000a37] [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [static] Loaded fake backend for rdpsnd [16:07:13:869] [2614:00000a37] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel ainput [16:07:13:869] [2614:00000a37] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpgfx [16:07:13:869] [2614:00000a37] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel disp [16:07:13:869] [2614:00000a37] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpsnd [16:07:13:945] [2614:00000a4c] [WARN][com.freerdp.channels.drdynvc.client] -
OnOpen=(nil), OnClose=0x7fceb2fd35c0 [16:07:16:911] [2614:00000a37] [WARN][com.freerdp.core.rdp] - [rdp_handle_sc_flags][0x55abdd84cc80]: [CONNECTION_STATE_FINALIZATION_CLIENT_SYNC] unexpected server message, expected flag FINALIZE_SC_SYNCHRONIZE_PDU [0x00000001] [have NO_FLAG_SET [0x00000000]] [16:07:16:911] [2614:00000a37] [WARN][com.freerdp.core.rdp] - [rdp_handle_sc_flags][0x55abdd84cc80]: [CONNECTION_STATE_FINALIZATION_CLIENT_SYNC] unexpected server message, expected flag FINALIZE_SC_SYNCHRONIZE_PDU [0x00000001] [have NO_FLAG_SET [0x00000000]] [16:07:17:902] [2614:00000a49] [WARN][com.freerdp.channels.rdpdr.client]
With the successful connection using xfreerdp the only 2 messages in the xrdp.log are
[20240415-16:06:59] [ERROR] Cannot read certificate file /etc/xrdp/cert.pem: No such file or directory [20240415-16:07:00] [ERROR] Cannot read private key file /etc/xrdp/key.pem: No such file or directory
xrdp-sesman.log contains these 2 items
[20240415-16:07:13] [ERROR] sesman_data_in: scp_process_msg failed [20240415-16:07:13] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
Holler if you need anything else !
Thanks for investigating this with me.
-- Regards,
Joe
matt335672
commented
7 months ago Thanks.
There's very little in both logs. Have you dialled back the logging level? Can you set it to INFO if you have for both?
The other errors are maybe pointing to something. They're indicating that the negotiation of the dynamic client resize functionality is failing. This is the thing that doesn't work for the plasma 5 client. Are you able to disable this for the more modern client? I can't find any info on this online.
JoeSalmeri
commented
7 months ago On 4/16/24 5:08 AM, matt335672 wrote:
Thanks.
There's very little in both logs. Have you dialled back the logging level? Can you set it to INFO if you have for both?
I have not modified the logging levels.
In xrdp.ini and sesman.ini I found LogLevel and SysLogLevel and they were all set to ERROR, I changed them all INFO on the xrdp server and rebooted it.
Here is the xrdp.log when I attempt the krdc connection
[20240416-19:18:04] [INFO ] starting xrdp with pid 996 [20240416-19:18:05] [INFO ] address [0.0.0.0] port [3389] mode 1 [20240416-19:18:05] [INFO ] listening to port 3389 on 0.0.0.0 [20240416-19:18:06] [INFO ] xrdp_listen_pp done [20240416-19:21:10] [INFO ] Socket 11: AF_INET6 connection received from ::ffff:192.168.1.32 port 43720 [20240416-19:21:10] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem [20240416-19:21:10] [ERROR] Cannot read certificate file /etc/xrdp/cert.pem: No such file or directory [20240416-19:21:10] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem [20240416-19:21:10] [ERROR] Cannot read private key file /etc/xrdp/key.pem: No such file or directory [20240416-19:21:10] [WARN ] Cannot accept TLS connections because certificate or private key file is not readable. certificate file: [/etc/xrdp/cert.pem], private key file: [/etc/xrdp/key.pem] [20240416-19:21:10] [INFO ] Security protocol: configured [RDP], requested [SSL|HYBRID|RDP], selected [RDP] [20240416-19:21:10] [INFO ] Connected client computer name: twlatest [20240416-19:21:11] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored) [20240416-19:21:11] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored) [20240416-19:21:11] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00020409] [20240416-19:21:11] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options [] [20240416-19:21:11] [INFO ] Non-TLS connection established from ::ffff:192.168.1.32 port 43720: with security level : high [20240416-19:21:12] [INFO ] xrdp_caps_process_pointer: client supports new(color) cursor [20240416-19:21:12] [INFO ] xrdp_caps_process_codecs: RemoteFX, codec id 3, properties len 49 [20240416-19:21:12] [WARN ] Cannot find keymap file /etc/xrdp/km-00020409.ini [20240416-19:21:12] [INFO ] Loading keymap file /etc/xrdp/km-00000409.ini [20240416-19:21:12] [WARN ] local keymap file for 0x00020409 found and doesn't match built in keymap, using local keymap file [20240416-19:21:12] [ERROR] dynamic_monitor_open_response: error [20240416-19:21:12] [ERROR] xrdp_rdp_recv: xrdp_channel_process failed
The keymap file that it mentions says is missing /etc/xrdp/km-00020409.ini
Does not exist on the xrdp server but there is one that is close in name
km-00000409.iniThere are 21 km*.ini files and 2 symlinks that are all created during the installation of xrdp.
The last 2 errors seem to be related to the dynamic monitor stuff you mentioned.
The xrdp-sesman.log file only contains this line
[20240416-19:18:04] [INFO ] starting xrdp-sesman with pid 995
The other errors are maybe pointing to something. They're indicating that the negotiation of the dynamic client resize functionality is failing. This is the thing that doesn't work for the plasma 5 client. Are you able to disable this for the more modern client? I can't find any info on this online.
Krdc has a setting "Resize to fit" which is enabled by default.
I tried turning of that global krdc setting and rerunning the above but the only differences in the logs were the times and the port numbers
When I run xfreerdp, I use the --dynamic-resolution option and it works properly when I maximize the xfreerdp window, so it doesn't seem like xrdp has a problem with the dynamic sizing.
-- Regards,
Joe
matt335672
commented
7 months ago Thanks.
Your requested keymap file is explained as follows; The number '00020409' is the input locale for 'United States - International' (see here). We don't have a separate keyboard definition for that, so the system falls back to 'US' (0409). That's fairly normal and shouldn't pose any problems.
You've got nothing in the logs which suggests the system is attempting to start a session. It looks like xrdp is hanging before it gets that far, or krdc is giving up
Can you change the log level to DEBUG on xrdp? That will really hit performance but we might get some more info out.
JoeSalmeri
commented
6 months ago @matt335672
FYI, Generally I have been updating the 2 vms to the latest TW versions before doing a test in case a newer build magically fixes things. They were on 20240416 and I updated to 20240419 today.
After updating to 20240419 I changed the xrdp.ini to use LogLevel=DEBUG and SyslogLevel=DEBUG and rebooted rdp server.
Then on the 2nd vm I attempted to connect to xrdp on the rdp server using krdc
xrdp.log
[20240422-12:33:31] [INFO ] starting xrdp with pid 3665 [20240422-12:33:31] [INFO ] address [0.0.0.0] port [3389] mode 1 [20240422-12:33:32] [INFO ] listening to port 3389 on 0.0.0.0 [20240422-12:33:32] [INFO ] xrdp_listen_pp done
xrdp-sesman.log
[20240422-12:33:31] [INFO ] starting xrdp-sesman with pid 3664
There were no debug messages and I verified that /etc/xrdp/xrdp.ini has both loglevels set to DEBUG.
krdc console messages
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)
I don't know what the metadata is that it is complaining about but they are they are the same messages as previously reported in an earlier message. Krdc seems to fail/crash before it even gets to the connection phase.
Connecting from the 2nd vm ( same client where krdc crashes ) using xfreerdp works as it has in all the other tests.
matt335672
commented
6 months ago Here's an interesting PR from the krdc sources:-
https://github.com/KDE/krdc/commit/6ba6edcaeffc480c6bd6ff14131a310753e42cf6
It's a bit of a long shot, but have a look for krdc_*,json files on your system, take copies, and try making the same change.
JoeSalmeri
commented
6 months ago @matt335672
Ok, I will check that out.
Here's some additional info regarding the test with the loglevels set to DEBUG.
Instead of using the vm client that is running the latest TW and which I have been updating, I used a client that is still running TW 20240329 and I ran krdc from the cmdline.
There I don't get the coredump and I do get those same messages, however, after the KBookmarManager::changed message instead of the coredump I get:
KRDC: Starting RDP session [13:19:48:227] [7555:7555] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_RGBA32 [13:19:48:228] [7555:7555] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32 [13:19:48:240] [7555:7555] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded pulse backend for rdpsnd [13:19:48:241] [7555:7555] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpsnd [13:19:48:241] [7555:7555] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel audin [13:19:48:250] [7555:7555] [INFO][com.freerdp.channels.audin.client] - Loaded pulse backend for audin [13:19:48:250] [7555:7555] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
It never displays the desktop and just displays the blue screen.
You are right about it being much slower but now you get some DEBUG messages
Here is the xrdp.log from using that older client
[20240422-13:19:10] [INFO ] starting xrdp with pid 3258
[20240422-13:19:10] [INFO ] address [0.0.0.0] port [3389] mode 1
[20240422-13:19:10] [INFO ] listening to port 3389 on 0.0.0.0
[20240422-13:19:11] [INFO ] xrdp_listen_pp done
[20240422-13:19:34] [INFO ] Socket 11: AF_INET6 connection received from ::ffff:192.168.1.1 port 37228
[20240422-13:19:35] [DEBUG] Closed socket 11 (AF_INET6 ::ffff:192.168.1.20 port 3389)
[20240422-13:19:35] [DEBUG] Closed socket 10 (AF_INET6 :: port 3389)
[20240422-13:19:35] [DEBUG] item ini_version, value 1
[20240422-13:19:35] [DEBUG] item fork, value true
[20240422-13:19:35] [DEBUG] item port, value 3389
[20240422-13:19:35] [DEBUG] item use_vsock, value false
[20240422-13:19:35] [DEBUG] item tcp_nodelay, value true
[20240422-13:19:36] [DEBUG] item tcp_keepalive, value true
[20240422-13:19:36] [DEBUG] item security_layer, value negotiate
[20240422-13:19:36] [DEBUG] item crypt_level, value high
[20240422-13:19:36] [DEBUG] item certificate, value
[20240422-13:19:36] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20240422-13:19:36] [ERROR] Cannot read certificate file /etc/xrdp/cert.pem: No such file or directory
[20240422-13:19:36] [DEBUG] item key_file, value
[20240422-13:19:36] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20240422-13:19:37] [ERROR] Cannot read private key file /etc/xrdp/key.pem: No such file or directory
[20240422-13:19:37] [DEBUG] item ssl_protocols, value TLSv1.2, TLSv1.3
[20240422-13:19:37] [DEBUG] TLSv1.3 enabled
[20240422-13:19:37] [DEBUG] TLSv1.2 enabled
[20240422-13:19:37] [DEBUG] item autorun, value
[20240422-13:19:37] [DEBUG] item allow_channels, value true
[20240422-13:19:37] [DEBUG] item allow_multimon, value true
[20240422-13:19:37] [DEBUG] item bitmap_cache, value true
[20240422-13:19:38] [DEBUG] item bitmap_compression, value true
[20240422-13:19:38] [DEBUG] item bulk_compression, value true
[20240422-13:19:38] [DEBUG] item max_bpp, value 32
[20240422-13:19:38] [DEBUG] item new_cursors, value true
[20240422-13:19:38] [DEBUG] item use_fastpath, value both
[20240422-13:19:38] [DEBUG] item blue, value 009cb5
[20240422-13:19:39] [DEBUG] item grey, value dedede
[20240422-13:19:39] [DEBUG] item ls_top_window_bg_color, value 000000
[20240422-13:19:39] [DEBUG] item ls_width, value 350
[20240422-13:19:39] [DEBUG] item ls_height, value 430
[20240422-13:19:39] [DEBUG] item ls_bg_color, value dedede
[20240422-13:19:39] [DEBUG] item ls_logo_filename, value
[20240422-13:19:40] [DEBUG] item ls_logo_x_pos, value 55
[20240422-13:19:40] [DEBUG] item ls_logo_y_pos, value 50
[20240422-13:19:40] [DEBUG] item ls_label_x_pos, value 30
[20240422-13:19:40] [DEBUG] item ls_label_width, value 65
[20240422-13:19:40] [DEBUG] item ls_input_x_pos, value 110
[20240422-13:19:40] [DEBUG] item ls_input_width, value 210
[20240422-13:19:41] [DEBUG] item ls_input_y_pos, value 220
[20240422-13:19:41] [DEBUG] item ls_btn_ok_x_pos, value 142
[20240422-13:19:41] [DEBUG] item ls_btn_ok_y_pos, value 370
[20240422-13:19:41] [DEBUG] item ls_btn_ok_width, value 85
[20240422-13:19:41] [DEBUG] item ls_btn_ok_height, value 30
[20240422-13:19:41] [DEBUG] item ls_btn_cancel_x_pos, value 237
[20240422-13:19:42] [DEBUG] item ls_btn_cancel_y_pos, value 370
[20240422-13:19:42] [DEBUG] item ls_btn_cancel_width, value 85
[20240422-13:19:42] [DEBUG] item ls_btn_cancel_height, value 30
[20240422-13:19:42] [WARN ] Cannot accept TLS connections because certificate or private key file is not readable. certificate file: [/etc/xrdp/cert.pem], private key file: [/etc/xrdp/key.pem]
[20240422-13:19:42] [INFO ] Security protocol: configured [RDP], requested [SSL|HYBRID|RDP], selected [RDP]
[20240422-13:19:42] [DEBUG] Using RDP security, and reading the server configuration
[20240422-13:19:42] [DEBUG] [MCS Connection Sequence] receive connection request
[20240422-13:19:42] [INFO ] Connected client computer name: XXXPC
[20240422-13:19:43] [DEBUG] Client supports 40 bit encryption
[20240422-13:19:43] [DEBUG] Client supports 128 bit encryption
[20240422-13:19:43] [DEBUG] Client supports 56 bit encryption
[20240422-13:19:43] [DEBUG] Client supports fips encryption
[20240422-13:19:43] [DEBUG] Client and server both support high encryption, using RDP 128-bit encryption.
[20240422-13:19:43] [DEBUG] Adding channel: name rdpdr, channel id 1004, flags 0xc0800000
[20240422-13:19:43] [DEBUG] Adding channel: name rdpsnd, channel id 1005, flags 0xc0000000
[20240422-13:19:44] [DEBUG] Adding channel: name cliprdr, channel id 1006, flags 0xc0a00000
[20240422-13:19:44] [DEBUG] Adding channel: name drdynvc, channel id 1007, flags 0xc0800000
[20240422-13:19:44] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored)
[20240422-13:19:44] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored)
[20240422-13:19:44] [DEBUG] [MCS Connection Sequence] construct connection response
[20240422-13:19:44] [DEBUG] using 2048 bit RSA key
[20240422-13:19:44] [DEBUG] [MCS Connection Sequence] send connection response
[20240422-13:19:44] [DEBUG] [MCS Connection Sequence] receive erect domain request
[20240422-13:19:44] [DEBUG] [MCS Connection Sequence] receive attach user request
[20240422-13:19:44] [DEBUG] [MCS Connection Sequence] send attach user confirm
[20240422-13:19:45] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00020409]
[20240422-13:19:45] [DEBUG] keyboard_cfg_file /etc/xrdp/xrdp_keyboard.ini
[20240422-13:19:45] [DEBUG] xrdp_load_keyboard_layout: item rdp_layout_us value 0x00000409
[20240422-13:19:45] [DEBUG] xrdp_load_keyboard_layout: skipping configuration item - rdp_layout_us, continuing to next section
[20240422-13:19:45] [DEBUG] xrdp_load_keyboard_layout: item rdp_layout_us value us
[20240422-13:19:45] [DEBUG] xrdp_load_keyboard_layout: skipping configuration item - rdp_layout_us, continuing to next section
[20240422-13:19:45] [DEBUG] xrdp_load_keyboard_layout: item keyboard_type value 4
[20240422-13:19:45] [DEBUG] xrdp_load_keyboard_layout: item keyboard_subtype value 3
[20240422-13:19:45] [DEBUG] xrdp_load_keyboard_layout: item keyboard_type value 7
[20240422-13:19:45] [DEBUG] xrdp_load_keyboard_layout: item keyboard_subtype value 2
[20240422-13:19:46] [DEBUG] xrdp_load_keyboard_layout: item model value pc105
[20240422-13:19:46] [DEBUG] xrdp_load_keyboard_layout: item rdp_layouts value default_rdp_layouts
[20240422-13:19:46] [DEBUG] xrdp_load_keyboard_layout: item layouts_map value default_layouts_map
[20240422-13:19:46] [DEBUG] xrdp_load_keyboard_layout: item rdp_layout_us value us
[20240422-13:19:46] [DEBUG] xrdp_load_keyboard_layout: skipping configuration item - rdp_layout_us, continuing to next section
[20240422-13:19:46] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20240422-13:19:46] [INFO ] Non-TLS connection established from ::ffff:192.168.1.1 port 37228: with security level : high
[20240422-13:19:47] [DEBUG] [MCS Connection Sequence] completed
[20240422-13:19:47] [DEBUG] Client requested auto logon.
[20240422-13:19:47] [DEBUG] Client requested compression enabled.
[20240422-13:19:47] [DEBUG] Client supplied password is empty, disabling autologin
[20240422-13:19:47] [DEBUG] Client supplied domain:
[20240422-13:19:47] [DEBUG] Client supplied username: joe
[20240422-13:19:47] [DEBUG] Client supplied password:
Here is the xrdp-sesman.log
[20240422-13:19:10] [INFO ] starting xrdp-sesman with pid 3257
Ok, off to checking out the link you posted to see what that recommends.
Thanks!
JoeSalmeri
commented
6 months ago @matt335672
Here's an interesting PR from the krdc sources:-
Ok, did a search and none of those files are found on my systems.
Looks like they are part of the xrdp source code.
It says the commit was from a last month and considering how fast TW moves, I would be surprised that it was not in the latest builds but the errors from the newer TW client sure look like they are talking about what you found.
matt335672
commented
6 months ago I've had a look at this error:-
[20240422-13:19:56] [ERROR] dynamic_monitor_open_response: errorIt's a response from the client when we try to open the dynamic channel for client resize support. I've no idea why the client should be bouncing this, and it doesn't seem to be logging anything.
You could try disabling drdynvc in the `[Channels]' section in xrdp.ini. That should prevent the error, and may give us some more clues, but at the moment it's all a bit of a mystery.
JoeSalmeri
commented
6 months ago @matt335672
Ok, I tried changing that but it made same results.
Note that "xfreerdp -u joe -v rdtptemp --dynamic-resolution" continues to work fine and it dynamically resizes when window size is maximized.
matt335672
commented
6 months ago Interesting.
If I'm understanding you, that's not what I see here.
My /etc/xrdp/xrdp.ini has:-
[Channels]
; Channel names not listed here will be blocked by XRDP.
; You can block any channel by setting its value to false.
; IMPORTANT! All channels are not supported in all use
; cases even if you set all values to true.
; You can override these settings on each session type
; These settings are only used if allow_channels=true
rdpdr=true
rdpsnd=true
drdynvc=false
cliprdr=true
rail=true
xrdpvr=true
tcutils=trueOnce I'm logged out, I restart xrdp with sudo systemctl restart xrdp
When I connect with:-
xfreerdp /dynamic-resolution /v:xrdp-test.test.lan /u:xxxxxxx /d: /p:xxxxxxxI can't resize the session window I get.
Is that what you're seeing, or am I misunderstanding you?
JoeSalmeri
commented
6 months ago @matt335672
The "default" xrdp.ini contains:
[Channels] ; Channel names not listed here will be blocked by XRDP. ; You can block any channel by setting its value to false. ; IMPORTANT! All channels are not supported in all use ; cases even if you set all values to true. ; You can override these settings on each session type ; These settings are only used if allow_channels=true rdpdr=true rdpsnd=true drdynvc=true cliprdr=true rail=true xrdpvr=true tcutils=true
After connecting the screen resolution is 1024x768.
If I double click the title bar of the xfreerdp window then the resolution changes to 2410x1412.
If I double click the title bar again it goes back to 1024x768 and then I can drag the window edges to resize to my hearts content and it will dynamically resize.
My point earlier was that even though you saw that message, the dynamic resizing worked fine when using xfreerdp.
If I modify xrdp.ini to use drdynvc=false and the systemctl restart xrdp, then the xfreerdp window does NOT dynamically adjust the resolution when the window is resized, BUT, I can change the resolution manually and the resolution change works and it resizes the xfreerdp window.
If I leave drdynvc=false and try to connect using
krdc rdp://joe@rdptemp
then I get the following console messages
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 [11:20:36:301] [14962:14962] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_RGBA32 [11:20:36:301] [14962:14962] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32 [11:20:36:311] [14962:14962] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded pulse backend for rdpsnd [11:20:36:312] [14962:14962] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpsnd [11:20:36:312] [14962:14962] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel audin [11:20:36:315] [14962:14962] [INFO][com.freerdp.channels.audin.client] - Loaded pulse backend for audin [11:20:36:315] [14962:14962] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
and the window is the blue screen but never displays the desktop.
If I run 'xrdp-sesadmin -u=xxx -c=list' ( on the rdptemp server ) I get:
[20240506-11:21:45] [INFO ] [v1c_mng:418] connection ok No sessions.
xrdp.log contains
[20240506-11:18:19] [INFO ] starting xrdp with pid 3289
[20240506-11:18:19] [INFO ] address [0.0.0.0] port [3389] mode 1
[20240506-11:18:19] [INFO ] listening to port 3389 on 0.0.0.0
[20240506-11:18:20] [INFO ] xrdp_listen_pp done
[20240506-11:20:25] [INFO ] Socket 11: AF_INET6 connection received from ::ffff:192.168.1.1 port 52606
[20240506-11:20:25] [DEBUG] Closed socket 11 (AF_INET6 ::ffff:192.168.1.20 port 3389)
[20240506-11:20:25] [DEBUG] Closed socket 10 (AF_INET6 :: port 3389)
[20240506-11:20:25] [DEBUG] item ini_version, value 1
[20240506-11:20:25] [DEBUG] item fork, value true
[20240506-11:20:25] [DEBUG] item port, value 3389
[20240506-11:20:26] [DEBUG] item use_vsock, value false
[20240506-11:20:26] [DEBUG] item tcp_nodelay, value true
[20240506-11:20:26] [DEBUG] item tcp_keepalive, value true
[20240506-11:20:26] [DEBUG] item security_layer, value negotiate
[20240506-11:20:26] [DEBUG] item crypt_level, value high
[20240506-11:20:26] [DEBUG] item certificate, value
[20240506-11:20:26] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20240506-11:20:26] [ERROR] Cannot read certificate file /etc/xrdp/cert.pem: No such file or directory
[20240506-11:20:26] [DEBUG] item key_file, value
[20240506-11:20:26] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20240506-11:20:27] [ERROR] Cannot read private key file /etc/xrdp/key.pem: No such file or directory
[20240506-11:20:27] [DEBUG] item ssl_protocols, value TLSv1.2, TLSv1.3
[20240506-11:20:27] [DEBUG] TLSv1.3 enabled
[20240506-11:20:27] [DEBUG] TLSv1.2 enabled
[20240506-11:20:27] [DEBUG] item autorun, value
[20240506-11:20:27] [DEBUG] item allow_channels, value true
[20240506-11:20:27] [DEBUG] item allow_multimon, value true
[20240506-11:20:27] [DEBUG] item bitmap_cache, value true
[20240506-11:20:27] [DEBUG] item bitmap_compression, value true
[20240506-11:20:28] [DEBUG] item bulk_compression, value true
[20240506-11:20:28] [DEBUG] item max_bpp, value 32
[20240506-11:20:28] [DEBUG] item new_cursors, value true
[20240506-11:20:28] [DEBUG] item use_fastpath, value both
[20240506-11:20:28] [DEBUG] item blue, value 009cb5
[20240506-11:20:28] [DEBUG] item grey, value dedede
[20240506-11:20:28] [DEBUG] item ls_top_window_bg_color, value 000000
[20240506-11:20:28] [DEBUG] item ls_width, value 350
[20240506-11:20:28] [DEBUG] item ls_height, value 430
[20240506-11:20:28] [DEBUG] item ls_bg_color, value dedede
[20240506-11:20:28] [DEBUG] item ls_logo_filename, value
[20240506-11:20:29] [DEBUG] item ls_logo_x_pos, value 55
[20240506-11:20:29] [DEBUG] item ls_logo_y_pos, value 50
[20240506-11:20:29] [DEBUG] item ls_label_x_pos, value 30
[20240506-11:20:29] [DEBUG] item ls_label_width, value 65
[20240506-11:20:29] [DEBUG] item ls_input_x_pos, value 110
[20240506-11:20:29] [DEBUG] item ls_input_width, value 210
[20240506-11:20:29] [DEBUG] item ls_input_y_pos, value 220
[20240506-11:20:29] [DEBUG] item ls_btn_ok_x_pos, value 142
[20240506-11:20:29] [DEBUG] item ls_btn_ok_y_pos, value 370
[20240506-11:20:30] [DEBUG] item ls_btn_ok_width, value 85
[20240506-11:20:30] [DEBUG] item ls_btn_ok_height, value 30
[20240506-11:20:30] [DEBUG] item ls_btn_cancel_x_pos, value 237
[20240506-11:20:30] [DEBUG] item ls_btn_cancel_y_pos, value 370
[20240506-11:20:30] [DEBUG] item ls_btn_cancel_width, value 85
[20240506-11:20:30] [DEBUG] item ls_btn_cancel_height, value 30
[20240506-11:20:30] [WARN ] Cannot accept TLS connections because certificate or private key file is not readable. certificate file: [/etc/xrdp/cert.pem], private key file: [/etc/xrdp/key.pem]
[20240506-11:20:30] [INFO ] Security protocol: configured [RDP], requested [SSL|HYBRID|RDP], selected [RDP]
[20240506-11:20:30] [DEBUG] Using RDP security, and reading the server configuration
[20240506-11:20:30] [DEBUG] [MCS Connection Sequence] receive connection request
[20240506-11:20:31] [INFO ] Connected client computer name: XXXpc
[20240506-11:20:31] [DEBUG] Client supports 40 bit encryption
[20240506-11:20:31] [DEBUG] Client supports 128 bit encryption
[20240506-11:20:31] [DEBUG] Client supports 56 bit encryption
[20240506-11:20:31] [DEBUG] Client supports fips encryption
[20240506-11:20:31] [DEBUG] Client and server both support high encryption, using RDP 128-bit encryption.
[20240506-11:20:31] [DEBUG] Adding channel: name rdpdr, channel id 1004, flags 0xc0800000
[20240506-11:20:31] [DEBUG] Adding channel: name rdpsnd, channel id 1005, flags 0xc0000000
[20240506-11:20:31] [DEBUG] Adding channel: name cliprdr, channel id 1006, flags 0xc0a00000
[20240506-11:20:31] [DEBUG] Adding channel: name drdynvc, channel id 1007, flags 0xc0800000
[20240506-11:20:32] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored)
[20240506-11:20:32] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored)
[20240506-11:20:32] [DEBUG] [MCS Connection Sequence] construct connection response
[20240506-11:20:32] [DEBUG] using 2048 bit RSA key
[20240506-11:20:32] [DEBUG] [MCS Connection Sequence] send connection response
[20240506-11:20:32] [DEBUG] [MCS Connection Sequence] receive erect domain request
[20240506-11:20:32] [DEBUG] [MCS Connection Sequence] receive attach user request
[20240506-11:20:32] [DEBUG] [MCS Connection Sequence] send attach user confirm
[20240506-11:20:32] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00020409]
[20240506-11:20:33] [DEBUG] keyboard_cfg_file /etc/xrdp/xrdp_keyboard.ini
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: item rdp_layout_us value 0x00000409
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: skipping configuration item - rdp_layout_us, continuing to next section
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: item rdp_layout_us value us
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: skipping configuration item - rdp_layout_us, continuing to next section
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: item keyboard_type value 4
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: item keyboard_subtype value 3
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: item keyboard_type value 7
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: item keyboard_subtype value 2
[20240506-11:20:33] [DEBUG] xrdp_load_keyboard_layout: item model value pc105
[20240506-11:20:34] [DEBUG] xrdp_load_keyboard_layout: item rdp_layouts value default_rdp_layouts
[20240506-11:20:34] [DEBUG] xrdp_load_keyboard_layout: item layouts_map value default_layouts_map
[20240506-11:20:34] [DEBUG] xrdp_load_keyboard_layout: item rdp_layout_us value us
[20240506-11:20:34] [DEBUG] xrdp_load_keyboard_layout: skipping configuration item - rdp_layout_us, continuing to next section
[20240506-11:20:34] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20240506-11:20:34] [INFO ] Non-TLS connection established from ::ffff:192.168.1.1 port 52606: with security level : high
[20240506-11:20:35] [DEBUG] [MCS Connection Sequence] completed
[20240506-11:20:35] [DEBUG] Client requested auto logon.
[20240506-11:20:35] [DEBUG] Client requested compression enabled.
[20240506-11:20:35] [DEBUG] Client supplied password is empty, disabling autologin
[20240506-11:20:35] [DEBUG] Client supplied domain:
[20240506-11:20:35] [DEBUG] Client supplied username: joe
[20240506-11:20:35] [DEBUG] Client supplied password:
xrdp-sesman.log contains
[20240506-11:18:19] [DEBUG] libscp initialized [20240506-11:18:19] [INFO ] starting xrdp-sesman with pid 3288 [20240506-11:18:19] [DEBUG] sesman_create_listening_transport: address 127.0.0.1 port 3350 [20240506-11:21:44] [INFO ] Socket 11: AF_INET6 connection received from ::1 port 47126 [20240506-11:21:45] [DEBUG] [v1s:242] requested management connection [20240506-11:21:45] [INFO ] starting a sesman management session... [20240506-11:21:45] [INFO ] [MNG] Terminal Server Admin group is disabled, allowing authentication [20240506-11:21:45] [INFO ] [v1s_mng:422] request session list [20240506-11:21:45] [DEBUG] searching for session by user: (null) [20240506-11:21:45] [INFO ] No sessions on Terminal Server [20240506-11:21:45] [WARN ] [v1s_mng:379] connection aborted: network error [20240506-11:21:45] [WARN ] libscp network error. [20240506-11:21:45] [ERROR] sesman_data_in: scp_process_msg failed [20240506-11:21:46] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans [20240506-11:21:46] [DEBUG] Closed socket 11 (AF_INET6 ::1 port 3350)
All the issues are with krdc.
xfreerdp works fine even with the dynamic resizing ( if I change back to drdynvc=true ).
matt335672
commented
6 months ago OK - thanks. That's clear now.
xrdp has received the client info from krdc. It thinks it's drawn the login box, and it's waiting for input from the client.
What really isn't clear is why krdc is not displaying the login box.
I'm really grubbing around for ideas now, but I notice that the client supports multimon. There's not another monitor plugged into the client is there, maybe turned off or switched to another input?
JoeSalmeri
commented
6 months ago @matt335672
Normally I have the password saved ( so no login box ) so that I can just click on the connection but for this test environment I have not done that because that because you had asked me to try without a password so I never saved for these tests.
I have two 27" monitors on this system, but they are both always on. I tend to have a full screen app ( like a virtual machine ) on the 2nd monitor, but I get the same results even when nothing is displayed on the 2nd monitor and when I the blue screen with krdc, the krdc window is being displayed on the primary monitor.
Joe
matt335672
commented
6 months ago OK thanks. It was a bit of a long shot, but I've certainly been hit by that in the past.
I don't have any useful ideas at this point.
The only thing that's left that I can think of is the actual hostname you're using, but that surely can't be it. What else is left?
JoeSalmeri
commented
6 months ago @matt335672
Originally this all started because I renamed one of the servers that I use for xrdp, but in the test environment ( where I keep updating to the latest TW builds ) they were clean installs so the server rename hasn't happen in those environments.
Since the issues happen on other machines besides the test environment I don't see how the hostname could be a factor.
To me the issues is are all in krdc since xfreerdp works. The only time that xfreerdp has has any problem connecting is if I had previously attempted with krdc and the reason that xfreerdp has a problem then is because when krdc had the issue it the user systemd process and a bunch of others were left running. If I kill all those user processes and then retry using xfreerdp then it works.
Here's something NEW that you may find interesting.
I updated my main PC ( which also runs xrdp server ) to TW 20240430.
With this TW build installed if I
krdc rdp://denise@mypc
Then I do NOT get the blue screen AND I actually see it display the desktop and then immediately get
"The connection to the server was closed"
Here is the information from the console where krdc was started
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 [09:48:27:985] [32398:32398] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_RGBA32 [09:48:27:985] [32398:32398] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGR24 [09:48:27:990] [32398:32398] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded pulse backend for rdpsnd [09:48:27:990] [32398:32398] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpsnd [09:48:27:990] [32398:32398] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel audin [09:48:27:993] [32398:32398] [INFO][com.freerdp.channels.audin.client] - Loaded pulse backend for audin [09:48:27:993] [32398:32398] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx [09:48:30:134] [32398:32474] [WARN][com.freerdp.channels.rdpdr.client] - Checking ExtendedPDU::RDPDR_USER_LOGGEDON_PDU, client supported, server not found [09:48:30:417] [32398:32482] [ERROR][com.freerdp.core.update] - UPDATE_TYPE Bitmap [1] failed [09:48:30:417] [32398:32482] [ERROR][com.freerdp.core.rdp] - DATA_PDU_TYPE_UPDATE - update_recv() failed [09:48:30:417] [32398:32482] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1 [09:48:30:417] [32398:32482] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0 [09:48:32:467] [32398:32398] [ERROR][com.freerdp.core] - freerdp_abort_connect:freerdp_set_last_error_ex ERRCONNECT_CONNECT_CANCELLED [0x0002000B]
I am using the default xrdp.ini config on this machine but here is the the xrdp.log for that attempt:
[20240508-09:48:26] [ERROR] Cannot read certificate file /etc/xrdp/cert.pem: No such file or directory [20240508-09:48:26] [ERROR] Cannot read private key file /etc/xrdp/key.pem: No such file or directory [20240508-09:48:30] [ERROR] dynamic_monitor_open_response: error [20240508-09:48:30] [ERROR] xrdp_rdp_recv: xrdp_channel_process failed [20240508-09:48:30] [ERROR] xrdp_iso_send: trans_write_copy_s failed [20240508-09:48:30] [ERROR] Sending [ITU T.125] DisconnectProviderUltimatum failed
Here is the xrdp-sesman.log
[20240508-09:48:27] [ERROR] sesman_data_in: scp_process_msg failed [20240508-09:48:27] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
Running "xrdp-sesadmin -u=root -c=list" returns the following:
[20240508-09:50:54] [INFO ] [v1c_mng:418] connection ok Session ID: 32483 Session type: 2 Screen size: 2560x1440, color depth 24 Idle time: 0 day(s) 0 hour(s) 0 minute(s) Connected: 2024/05/08 09:48
And looking at the process list I do see the systemd process as well as all the other processes including Xvnc running for the user
I see the dynamic monitor error you mentioned before but krdc does not seem to have an option for turning that off, BUT it does have a --fullscreen option.
Running the krdc command above but with --fullscreen results in the fullscreen desktop showing for a second like above but and then displays the same "The connection to the server was closed" message.
If I kill all those processes and then try connecting using
xfreerdp -u denise -v mypc --dynamic-resolution
Then it connects and the desktop is displayed ( in 1024x768 resolution ) and I can double click the title bar and the window is resized and the resolution changes to match the new window size.
These results are DIFFERENT from what I have been seeing in my test vm environment.
I'm going to do some tests there where they are also running TW 20240430 and will report back.
JoeSalmeri
commented
6 months ago @matt335672
Ok in my test environment which was a clean TW install and which was updated to 20240430 if I try to from the rdp server back to the rdp server ( as a different user ) same test I did above by on mypc back to itself, then in the test environment, I get those similar message about the id issue and then krdc coredumps.
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
And in the test environment the coredump happens before it even gets connected ( unlike on mypc rdping back to itself )
Here's that xrdp.log
[20240508-10:37:56] [INFO ] starting xrdp with pid 13025 [20240508-10:37:56] [INFO ] address [0.0.0.0] port [3389] mode 1 [20240508-10:37:56] [INFO ] listening to port 3389 on 0.0.0.0 [20240508-10:37:56] [INFO ] xrdp_listen_pp done
Here's that xrdp-sesman.log
[20240508-10:37:56] [DEBUG] libscp initialized [20240508-10:37:56] [INFO ] starting xrdp-sesman with pid 13024 [20240508-10:37:56] [DEBUG] sesman_create_listening_transport: address 127.0.0.1 port 3350
This is kind of odd that mypc RDP back to itself shows the desktop and then gets the connection was closed message whereas the test vm gets the coredump since they are both running the same TW build and the test environment was just a new install and then a few updates to get it to the 20240430 build.
MyPC has other sw packages installed obviously.
The ONLY really difference I can think of is that MyPC is a real pc and the test vm is actually running on a different real pc that is hosting the kvm virtual machine, BUT, that real pc is a headless machine with no monitor/keyboard/mouse connected.
However, xfreerdp has no problems connecting to the rdp server running on the kvm host and also has no problems connecting to the rdp server running on the kvm guest test vm that I setup to debug all this, so it still comes back to krdc failing and xfreerdp working.
What I find strange is that it is my understanding that krdc may actually bu using xfreerdp behind the scenes.
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)
matt335672
commented
6 months ago Thanks.
The RDPDR_USER_LOGGEDON_PDU warning is interesting. This was raised as a problem our end by the FreeRDP team relating to drive redirection. See #2838. That's still a problem with the version of xrdp you have - it's fixed for version v0.10 (currently in beta).
Given the similarity in the message processing between krdc and freerdp, I think your assumption about krdc using freerdp is a safe one.
JoeSalmeri
commented
6 months ago @matt335672
Interest.....
/etc/xrdp/sesman.ini has this default setting in the test environment and default installation
FuseMountName=thinclient_drives
On MyPC I have changed it to
FuseMountName=/run/user/%u/thinclient_drives
The reason for the change was that because accessing the user's home directory when they were rdp'd as another user would cause problems for some software because of permissions on the thinclient_drives directory which would cause the software to have problems with cd'ing or using the users's home directory ( by another user ).
Moving that mount to /run/user/%u resolved that issue
I tried modifying the test environment to see if that would prevent the coredump that is occurring there but it still coredumps ( after changing sesman.ini and restarting xrdp ).
I am still perplexed by the fact that MyPC which was built last year and updated to TW 20240430 shows the desktop and then disconnects, whereas the test environment built when we started this discussion and updated to TW 20240430 just coredumps when you try to connect with krdc.
JoeSalmeri
commented
6 months ago @matt335672
FYI, just updated test environment to 20240506 and rdp back to itself still coredumps
I tried connecting from my pc ( which is still running 20240430 ) and it also still coredumps.
Not sure if this is helpful to you but here is the journal of the coredump
fc54:00ff:fe96:ef17 DST=ff02:0000:0000:0000:> May 08 11:56:48 systemd-coredump[17741]: [🡕] Process 17723 (krdc) of user 1000 dumped core.
Stack trace of thread 17723:
#0 0x00007f9d07eb7bf1 n/a (libkrdc_rdpplugin.so + 0xebf1)
#1 0x00007f9d07ebd48d n/a (libkrdc_rdpplugin.so + 0x1448d)
#2 0x00007f9d13e05245 _ZN15HostPreferences10showDialogEP7QWidget (libkrdccore.so.5 + 0xb245)
#3 0x000055784d74793b n/a (krdc + 0x3293b)
#4 0x000055784d731017 n/a (krdc + 0x1c017)
#5 0x00007f9d1162a1f0 __libc_start_call_main (libc.so.6 + 0x2a1f0)
#6 0x00007f9d1162a2b9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a2b9)
#7 0x000055784d7312d5 n/a (krdc + 0x1c2d5)
Stack trace of thread 17726:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11691d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40)
#2 0x00007f9d05d10e5b n/a (iris_dri.so + 0x110e5b)
#3 0x00007f9d05d06e67 n/a (iris_dri.so + 0x106e67)
#4 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#5 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17725:
#0 0x00007f9d1170578f __poll (libc.so.6 + 0x10578f)
#1 0x00007f9d0fc258aa n/a (libxcb.so.1 + 0xe8aa)
#2 0x00007f9d0fc2741c xcb_wait_for_event (libxcb.so.1 + 0x1041c)
#3 0x00007f9d0dd34e30 n/a (libQt6XcbQpa.so.6 + 0x5de30)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17724:
#0 0x00007f9d1170578f __poll (libc.so.6 + 0x10578f)
#1 0x00007f9d105ce2ff n/a (libglib-2.0.so.0 + 0x5f2ff)
#2 0x00007f9d105cea0c g_main_context_iteration (libglib-2.0.so.0 + 0x5fa0c)
#3 0x00007f9d121c0a8c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessE>
#4 0x00007f9d11f9979b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 +>
#5 0x00007f9d12074cb4 _ZN7QThread4execEv (libQt6Core.so.6 + 0x274cb4)
#6 0x00007f9d11d7b6fa n/a (libQt6DBus.so.6 + 0x386fa)
#7 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#8 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#9 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17735:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007f9d120f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2>
#3 0x00007f9d120f3d49 n/a (libQt6Core.so.6 + 0x2f3d49)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17736:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007f9d120f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2>
#3 0x00007f9d120f3d49 n/a (libQt6Core.so.6 + 0x2f3d49)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17738:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007f9d120f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2>
#3 0x00007f9d120f3d49 n/a (libQt6Core.so.6 + 0x2f3d49)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17737:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007f9d120f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2>
#3 0x00007f9d120f3d49 n/a (libQt6Core.so.6 + 0x2f3d49)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17739:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007f9d120f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2>
#3 0x00007f9d120f3d49 n/a (libQt6Core.so.6 + 0x2f3d49)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17727:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11691d40 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40)
#2 0x00007f9d05d10e5b n/a (iris_dri.so + 0x110e5b)
#3 0x00007f9d05d06e67 n/a (iris_dri.so + 0x106e67)
#4 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#5 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17731:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007f9d120f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2>
#3 0x00007f9d120f3d49 n/a (libQt6Core.so.6 + 0x2f3d49)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17733:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007f9d120f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2>
#3 0x00007f9d120f3d49 n/a (libQt6Core.so.6 + 0x2f3d49)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
Stack trace of thread 17734:
#0 0x00007f9d1168effe __futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007f9d11692065 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007f9d120f9413 _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2>
#3 0x00007f9d120f3d49 n/a (libQt6Core.so.6 + 0x2f3d49)
#4 0x00007f9d120ecea9 n/a (libQt6Core.so.6 + 0x2ecea9)
#5 0x00007f9d11692bb2 start_thread (libc.so.6 + 0x92bb2)
#6 0x00007f9d1171400c __clone3 (libc.so.6 + 0x11400c)
ELF object binary architecture: AMD x86-64@matt335672
Ok, just to point out that this is not just a Tumbeweed issue, I created a new vm that is running KDE Neon and updated to the latest figuring that it would be the place to have the latest krdc before anywhere else.
If I run krdc on the neon connecting back to the neon vm but at a different user, it also gets the blue screen.
Here are the logs from the neon server
xrdp.log
[20240508-12:31:15] [INFO ] Received termination signal, stopping the server accept new connections thread [20240508-12:31:20] [INFO ] address [0.0.0.0] port [3389] mode 1 [20240508-12:31:20] [INFO ] listening to port 3389 on 0.0.0.0 [20240508-12:31:20] [INFO ] xrdp_listen_pp done [20240508-12:31:22] [INFO ] starting xrdp with pid 3308 [20240508-12:31:23] [INFO ] address [0.0.0.0] port [3389] mode 1 [20240508-12:31:23] [INFO ] listening to port 3389 on 0.0.0.0 [20240508-12:31:23] [INFO ] xrdp_listen_pp done [20240508-12:32:00] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:127.0.0.1 port 58408 [20240508-12:32:00] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem [20240508-12:32:00] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem [20240508-12:32:00] [ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied [20240508-12:32:00] [INFO ] Connected client computer name: neon [20240508-12:32:00] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored) [20240508-12:32:00] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored) [20240508-12:32:01] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00020409] [20240508-12:32:01] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options [] [20240508-12:32:01] [INFO ] Non-TLS connection established from ::ffff:127.0.0.1 port 58408: encrypted with standard RDP security [20240508-12:32:01] [INFO ] xrdp_caps_process_pointer: client supports new(color) cursor [20240508-12:32:01] [INFO ] xrdp_caps_process_codecs: RemoteFX, codec id 3, properties len 49 [20240508-12:32:01] [WARN ] Cannot find keymap file /etc/xrdp/km-00020409.ini [20240508-12:32:01] [INFO ] Loading keymap file /etc/xrdp/km-00000409.ini [20240508-12:32:02] [WARN ] local keymap file for 0x00020409 found and doesn't match built in keymap, using local keymap file [20240508-12:32:02] [INFO ] connecting to sesman ip 127.0.0.1 port 3350 [20240508-12:32:02] [INFO ] xrdp_wm_log_msg: sesman connect ok [20240508-12:32:02] [INFO ] sesman connect ok [20240508-12:32:02] [INFO ] sending login info to session manager, please wait... [20240508-12:32:02] [ERROR] dynamic_monitor_open_response: error [20240508-12:32:02] [ERROR] xrdp_rdp_recv: xrdp_channel_process failed [20240508-12:32:05] [INFO ] xrdp_wm_log_msg: login failed for display 0 [20240508-12:32:05] [INFO ] login failed for display 0
xrdp-sesman.log
[20240508-12:31:15] [INFO ] shutting down sesman 1 [20240508-12:31:20] [INFO ] starting xrdp-sesman with pid 3298 [20240508-12:32:02] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 41584 [20240508-12:32:05] [ERROR] pam_authenticate failed: Authentication failure [20240508-12:32:05] [INFO ] Username or password error for user: denise [20240508-12:32:05] [ERROR] sesman_data_in: scp_process_msg failed [20240508-12:32:05] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing tra
And as I expected and matching my TW results, if I use
xfreerdp -u denise -v neon --dynamic-resolution
then xfreerdp connects without issue and if I double click the title bar then the window goes full screen and the rdp connection resolution dynamically updates.
So the problem exists across linux distros running kde when using the krdc client whereas the xfreerdp client always works.
JoeSalmeri
commented
6 months ago @matt335672
A few others tests........
A debian vm using plasma 5.27.5 and krdc 22.12.3 connects to the rdptemp server vm running plasma 6 and displays the desktop without issue.
A debian-sid vm using plasma 5.27.10 and krdc 23.08.3 connects to the rdptemp server vm running plasma 6 and displays the desktop without issue.
So the older krdc versions running on plasma 5 both seem to work fine connecting to the newer plasma 6 vm.
I updated the debian-sid vm to the latest version.
It is still using plasma 5 and krdc 23.08.3 and after installing the latest debian sid updates krdc still works.
So it seems very clear that the krdc 24 versions ( latest I have is 24.02.2 ) are at least part of the problem. Since xfreerdp always works I would think that xrdp is probably not contributing to the problem but it does occur in the session connection attempt so not sure whether krdc is unhappy with xrdp connection or xrdp is unhappy with krdc client.
Clearly this is a bigger problem than just Tumbleweed though since I can repo on other distros.
The common environment with the issue is plasma 6 and krdc 24.*.
Hope that is helpful.
Looks like TW 20240507 build was released while I was doing all that testing so I will update rdptemp test environment and see if that changes anything.
Stay tuned....
THANK YOU!
JoeSalmeri
commented
6 months ago @matt335672
TW 20240507 installed on rdptemp vm and when I try to connect back to itself as another user it core dumps.
Sigh :-(
matt335672
commented
6 months ago That's more great testing @JoeSalmeri
The coredump needs a debug RPM to fully decode, but the active thread is here:-
Stack trace of thread 17723:
#0 0x00007f9d07eb7bf1 n/a (libkrdc_rdpplugin.so + 0xebf1)
#1 0x00007f9d07ebd48d n/a (libkrdc_rdpplugin.so + 0x1448d)
#2 0x00007f9d13e05245 _ZN15HostPreferences10showDialogEP7QWidget (libkrdccore.so.5 + 0xb245)
#3 0x000055784d74793b n/a (krdc + 0x3293b)
#4 0x000055784d731017 n/a (krdc + 0x1c017)
#5 0x00007f9d1162a1f0 __libc_start_call_main (libc.so.6 + 0x2a1f0)
#6 0x00007f9d1162a2b9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a2b9)
#7 0x000055784d7312d5 n/a (krdc + 0x1c2d5)_ZN15HostPreferences10showDialogEP7QWidget decodes to HostPreferences::showDialog(QWidget*)
I've done some poking around, and I've come across your post on this thread-
https://bugs.kde.org/show_bug.cgi?id=482950
I'm not about next week, but after that, if you're still not getting any traction with KDE I'll try getting some debug RPMs on TW. I've not worked on that platform but I'm assuming its not hugely different from RHEL.
JoeSalmeri
commented
6 months ago Thanks @matt335672 I appreciate your help!
JoeSalmeri
commented
5 months ago @matt335672 FYI, I have added more testing to the bug report you referenced:
https://bugs.kde.org/show_bug.cgi?id=482950
New tests with other linux distros, some using plasma 5 and krdc 23. and others using plasma 6 and krdc 24. and even a test machine running Windows 11 using the build in RDP client.
It does not seem like anyone over there is doing anything to resolve the issues.
matt335672
commented
5 months ago Thanks for the update @JoeSalmeri
This is on the radar, but I'm struggling to catch up after some time away ATM.
matt335672
commented
5 months ago I've managed to reproduce this.
Connecting from TW 20240609 to my test machine xrdp-test.test.lan running v0.9.23.1, I get a blue screen.
Workaround for this is to use 24-bit colour:-
That all works fine now.
However, having set this up, this command coredumps:-
krdc rdp://xrdp-test.test.lanProblem is here:-
case Resolution::MatchWindow: {
auto *window = qApp->activeWindow();
if (window->parentWidget()) {
window = window->parentWidget();
}
rdpUi.kcfg_Width->setValue(window->width());
rdpUi.kcfg_Height->setValue(window->height());
break;
}qApp->activeWindow() returns a NULL, and this isn't checked.
I was going to report this on the KDE bug list, but it seems that it's difficult to do this without exposing an email address. I've been caught like this before. Any suggestions, @JoeSalmeri ?
JoeSalmeri
commented
5 months ago @matt335672
Thanks for investigating this Matt !
I've managed to reproduce this. Workaround for this is to use 24-bit colour:-
The 24 bit color trick did not work up through TW 20240524 which used krdc 24.02.2. Other suggestions on various forums talked about disabling accelleration but that never worked in my tests.
Since the krdc version wasn't changing for many TW builds I'd been waiting for a new krdc version to come out.
After seeing your msg, I updated my test environment and all my machines to TW 20240610 which has krdc version 24.05.0. ( It may have been included in versions after 20240524 as that was the last time I checked for a newer krdc version ).
After updating to 20240610 AND switching the saved connection to 24 bit color I can now successfully connect using krdc via the GUI or via the cmdline using 'krdc rdp://user@host', BUT, if you use the cmdline you have to already have saved the connection and configured it to use 24 bit color, otherwise it will default to 'Use Best Available' which does NOT work.
If you set color depth to either "true Color with Alpha ( 32 Bit )' OR 'Use Best Available' for the saved connection and start krdc via the cmdline using "krdc rdp://user@host" then you get:
Qt: Session management error: None of the authentication protocols specified are supported qt.core.qobject.connect: QObject::connect: No such signal KBookmarkManager::changed(QString, QString)
BUT, it is logging into the user because it plays the users login sound, it just doesn't display the desktop you only get the blue screen.
NOTE:
When testing, if you get the blue screen then processes for the user are left (like systemd , even after you kill krdc )
You MUST kill all the users processes for your "test" user before attempting again with changes ( like switching back
to 24 bit color ).
After killing all of the test user processes then you can login again using 24 bit color.I am not getting the coredump like you via the cmdline ( but did before switching to TW 20240610 ).
Having worked on this issue for months, it is easy to get a false test result, if you previously had a failed test so it is critical to make sure there are NO processes leftover from a previous test for the test user that is doing the RDP. I caught myself multiple times with that mistake so I always sanity check first now. Possible that might explain your cmdline coredump ( or you could be seeing the coredump issues I was reporting although they are not happening for me now on 20240610).
I was going to report this on the KDE bug list, but it seems that it's difficult to do this without exposing an email address. I've been caught like this before. Any suggestions, @JoeSalmeri ?
Is there a way I can reach you off this public forum ? I'm happy to tell you what I do but don't want to post that here for the same reasons you have.
I greatly appreciate all your efforts !
JoeSalmeri
commented
5 months ago @matt335672
One other point, I forgot to mention.
Before updating one of my machines from 20240430 to 20240610, I tried to use the 20240430 machine with krdc 24.02.2 to connect to the 20240610 machine using 24 bit color. That just failed with:
The connection to the server was closedAs soon as I updated the client to 20240610 ( so both client and server were using the newer TW and newer krdc ) then things worked as I described in my prior msg.
matt335672
commented
5 months ago I've just installed TW updates (13th June 2024) and rebooted. I got the coredump as before with the command line option.
I then played around with the settings in ~/.config/krdcrc. This was interesting. If the line resolution=0 is in the file I don't get the coredump.
I then ended up with the following minimal file which I could use to connect to xrdp-test.test.lan using 24-bit colour from the command line:-
[MainWindow]
ToolBarsMovable=Disabled
[hostpreferences][rdp://xrdp-test.test.lan]
acceleration=0
colorDepth=2
height=1280
keyboardLayout=7
resolution=0
scaleFactor=0
scaleToSize=false
showConfigAgain=false
width=1088I'm sure there's more that can be done to automate this.
Having got that far, I deleted the acceleration= and colorDepth= lines and tried again. I got a usable connection, which appears to be working with 32-bit colour! This is on a v0.10 development build, not v0.9. I had some keyboard issues, but I think that's because of the stuff I'm working on at present.
It's possible the non-display is down to some of the scaling code in krdc. That's a complete guess, but the above config disables that stuff.
I'm backing off getting involved on the KDE bug list at the moment. This is starting to look like it could be a real time sink, and given it doesn't seem to be an xrdp issue (and we've got plenty enough of our own troubles) I'm not sure I want to go down that route.
JoeSalmeri
commented
4 months ago @matt335672
Interesting about the resolution=0 config option. All of my entries have a resolution value but only 1 of them has it set to 0, most have it set to 4 or 5.
FWIW, I think the coredump with that version is because of it defaulting to 32 bit color.
If you create and save your config first using the GUI then you can save 24 bit color for that connection and then if you invoke via the cmdline it works because it is pre-configured for 24 bit color.
I appreciate all your help and efforts but am disappointed that you aren't submitting the bug that you found as I think it would carry much more weight coming from you.
matt335672
commented
4 months ago @JoeSalmeri - from what I've seen so far, I'm pretty confident that submitting a bug report for krdc isn't going to be a five minute job. Much (but not all) of this work we do on xrdp is unpaid, and so we have to choose quite carefully what we spend our effort on.
Can I turn this round? Our users range all the way from personal users to enterprises. It's not clear to me where you fit on that spectrum. My own background contains some enterprise-based systems analysis, and that part of my brain is wondering if krdc is the right product for your own workflow(s). You've mentioned that FreeRDP works for you. Is there some important part of your workflow(s) that FreeRDP doesn't meet, or is the product not aligned with your own requirements in some way?
JoeSalmeri
commented
4 months ago @matt335672
I'm sorry if I wasn't clear and I hope you didn't misunderstand what I wrote.
Although I am disappointed that you aren't going to submit the bug you identified, that doesn't mean I don't APPRECIATE all the work you've done ( I've said that many times ) and it also doesn't mean that I don't understand that you need to carefully choose where you spend your time since a lot of your work/efforts are volunteer and unpaid.
I didn't hope that you'd submit a bug report on all that we've investigated together, just a bug report on the NULL pointer being returned and not checked for that you found as that is probably the source of at least some of the coredumps we've both seen and problems that seem to be widespread across a bunch of different linux distros. Clearly dereferrencing the NULL pointer is going to cause a crash and produce an access denied error for memory address 0.
Since the krdc developers have been basically ignoring the user complaints about these issues since Plasma 6 was released I thought that they would give more weight to something reported by an xrdp developer.
Clearly I've proved many times that the problems have been with krdc and not xrdp and clearly you've gone ABOVE and BEYOND with your efforts ( MUCH APPRECIATED ) , but without good RDP client apps, xrdp wouldn't be very useful :-) and at least on KDE the main choice for a GUI RDP client seems to be krdc.
As for my background, I have been an independent consultant doing everything from network admin ( Linux and Windows ), to development ( in 25 different programming languages during my career ) with a large amount of time as a DBA ( Oracle, SqlServer, DB2 ) since the 1990's and worked with multiple large enterprise customers were our products were deployed and used in all 50 US states.
xfreerdp has worked for me but it is a cmdline based so not very friendly for novice end users whereas krdc is GUI based so more like end users expect and similar to their experience on Windows.
Since xfreerdp has worked and since they took so long to address the issues, I actually had considered writing my own GUI interface ( bare bones just for my needs ) to launch xfreerdp so that history and configurations could be saved but haven't had the free time to do it and kind of expected that the KDE people would not leave krdc broken for so long.
Thanks again for all the help you've provided.
matt335672
commented
4 months ago @JoeSalmeri - thanks for the clarification and the extra information.
Your background's not vastly different from mine (except I've never been a DBA).
When I was working an an enterprise systems admin one of my hats was researching products for use by a development team. If I was doing this again, looking for a GUI RDP client for Linux, I'd come up with the following - you've probably been down this path yourself, but there may be something useful here for you.
1) Definitely go with something written around FreeRDP. There's a huge amount of industry momentum behind it, and some good developers working on it - it's not going away any time soon. If an RDP feature you need isn't supported by FreeRDP you probably won't find it.
2) For a bespoke GUI wrapper to the command-line, there's at least one small project on github which you can possibly fork and make changes to, to meet your own requirements. You could even push contributions back. It's a good place to start, and given your background you'll experience a shallow learning curve. Disadvantage is that you may acquire some maintenance overhead (e.g. if you choose something based on Python).
3) Full-fat GUI wrappers which use the freerdp libraries are much harder to get right (as krdc demonstrates). I use remmina on my development workstation for informal testing. It works well for me, but other users have problems with it. There's some industry interest in it, so it may be worth you looking at.
4) krdc is part of the larger KDE project. That has advantages and disadvantages. One significant disadvantage is that the fault-reporting system is global for KDE so it's hard for anyone looking in to know who is working on any one sub-project. From what I've see so far, right now krdc is being a little neglected. That's only my opinion, I could be wrong, and on a project like KDE things will always change.
JoeSalmeri
commented
3 months ago @matt335672
Sorry for the delay, I was away. Thanks for that very useful summary, much appreciated.
xrdp version
0.9.23.1
Detailed xrdp version, build options
Operating system & version
openSUSE Tumbleweed 20240319
Installation method
dnf / apt / zypper / pkg / etc
Which backend do you use?
Xvnc
What desktop environment do you use?
KDE Plasma
Environment xrdp running on
Issue occurs with xrdp on a physical machine AND also reproduced in a VM
What's your client?
Testing using krdc and xfreerdp
Area(s) with issue?
Session manager (sesman)
Steps to reproduce
I have been using xrdp for YEARS and it has worked pretty much flawlessly.
Recently I renamed the server which xrdp is running on.
After the server rename it was rebooted and DNS and the routers were all updated to reflect the new name.
Remote machines can ping and ssh the new name, it is not a dns issue because everything resolves to the new name and nothing has any connectivity issues except for when I connect to the xrdp server using the new name.
I have rebooted all machines involved as well as the routers.
When I connect using krdc using the NEW name it just displays a blue screen and never displays the desktop but sometimes I hear it play the login sound.
If I try to use the OLD name with krdc then I get server not found.
Originally I thought this was a xrdp issue BUT I just found that if I use xfreerdp to connect to the NEW server name then it works perfectly.
On Windows machines if you attempt to connect using the NEW name then you get a certificate warning ( because the name changed ) and then after accepting it works fine.
I believe that xfreerdp works because it may have been built to default to an option to ignore certificate issues.
I have removed and reinstalled xrdp on the server in question and the problem persists.
I have also recreated the exact same issue if I have xrdp running in a VM and then I change the vm's host name ( and reboot and update DNS to reflect the new name ).
I believe that the issue is caused by a cached certificate on the clients that has the OLD hostname but I have not been able to find out how to delete it.
This reminds of of similar issue that occurs with ssh and known_hosts which occurs when a rename like this occurs.
Changing the xrdp server name back to the OLD hostname, rebooting and updating DNS/routers etc and then rdp works again.
Because that works and because everything else works when you rename except for krdc leads me to believe that some cached certificate is the cause but it doesn't prompt like Windows does to allow me to accept the new certificate.
✔️ Expected Behavior
RDP to connect and work using the NEW hostname
❌ Actual Behavior
See steps for full details but basically just get a blue screen and session is never displayed
Anything else?
See details in Steps but short answer is the blue screen