Problems connecting to xrdp server after host is renamed and rebooted #3021
Comments
|
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. |
|
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 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. |
|
You can use That might give you some clues as to where the cert store is, so you can delete it. |
|
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 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...... |
|
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 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 ??? |
|
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 You can examine the certificate xrdp is presenting to the client(s) with First, have a look in 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 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. |
|
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. 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.
Note that there are 5 lines in that file that look like this followed by the hex bytes that are the certificate [keys] 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 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 |
|
Here are a few pointers:-
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. |
|
|
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 |
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 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 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 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. |
|
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.... |
|
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. |
|
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] -
[check_open_close_receive]: {Microsoft::Windows::RDS::DisplayControl:1}
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] -
[check_open_close_receive]: {Microsoft::Windows::RDS::DisplayControl:1}
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] -
[check_open_close_receive]: {Microsoft::Windows::RDS::DisplayControl:1}
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]
- [rdpdr_check_extended_pdu_flag]: Checking
ExtendedPDU::RDPDR_USER_LOGGEDON_PDU, client supported, server not found
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
|
|
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. |
|
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.ini
There 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
|
|
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. |
|
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 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 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. |
|
Here's an interesting PR from the krdc sources:- It's a bit of a long shot, but have a look for |
|
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 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 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! |
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. |
|
I've had a look at this error:- It'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. |
|
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. |
|
Interesting. If I'm understanding you, that's not what I see here. My Once I'm logged out, I restart When I connect with:- I can't resize the session window I get. Is that what you're seeing, or am I misunderstanding you? |
|
The "default" xrdp.ini contains: [Channels] After connecting the screen resolution is 1024x768. If I double click the title bar of the xfreerdp window If I double click the title bar again it goes back My point earlier was that even though you saw that If I modify xrdp.ini to use drdynvc=false and the 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 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 xrdp.log contains [20240506-11:18:19] [INFO ] starting xrdp with pid 3289 xrdp-sesman.log contains [20240506-11:18:19] [DEBUG] libscp initialized All the issues are with krdc. xfreerdp works fine even with the dynamic resizing ( if I change back to drdynvc=true ). |
|
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? |
|
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 |
|
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? |
|
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 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 Here is the xrdp-sesman.log [20240508-09:48:27] [ERROR] sesman_data_in: scp_process_msg failed Running "xrdp-sesadmin -u=root -c=list" returns the following: [20240508-09:50:54] [INFO ] [v1c_mng:418] connection ok 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. |
|
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 Here's that xrdp-sesman.log [20240508-10:37:56] [DEBUG] libscp initialized 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 |
|
Thanks. The Given the similarity in the message processing between krdc and freerdp, I think your assumption about krdc using freerdp is a safe one. |
|
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. |
|
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:> |
|
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 xrdp-sesman.log [20240508-12:31:15] [INFO ] shutting down sesman 1 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. |
|
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. 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! |
|
TW 20240507 installed on rdptemp vm and when I try to connect back to itself as another user it core dumps. Sigh :-( |
|
That's more great testing @JoeSalmeri The coredump needs a debug RPM to fully decode, but the active thread is here:-
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. |
|
Thanks @matt335672 I appreciate your help! |
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
The text was updated successfully, but these errors were encountered: