Some sort of keepalive on xrdp connections is needed

[shooreek]

xrdp version

0.9.21.1

Detailed xrdp version, build options

PASTE HERE

Operating system & version

Linux

Installation method

dnf / apt / zypper / pkg / etc

Which backend do you use?

No response

What desktop environment do you use?

No response

Environment xrdp running on

No response

What's your client?

No response

Area(s) with issue?

Network

Steps to reproduce

1. Connect from Windows 10 client to xrdp server
2. Minimize the window -> wireshark on server indicates that no data is sent via port 3389
3. Wait 2-5 minutes

✔️ Expected Behavior

Connection is still alive

❌ Actual Behavior

Connection is lost, client gets disconnected

Anything else?

When I use the same Windows client to connect to Windows RDP server, I see that data is sent via port 3389 every 1-2 seconds or so even when RDP window is minimized. It keeps connection alive.

No disconnection occurs with xrdp server if I tell Windows client not to suppress remote desktop (HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\RemoteDesktop_SuppressWhenMinimized = 2). Constant desktop streaming keeps connection alive.

Please tell me if I need to provide additional information.

[matt335672]

I think this is expected behaviour. Without the DWORD, the client will send a Client Suppress Output PDU to the server which instructs it to not send any display updates.

There's no keepalive packet that I can find in the spec. The spec includes many virtual channels in addition to the graphical channel. I suspect that what is happening here is in a MS clent to MS server scenario, one of these channels has some data on it, and that channel isn't supported by xrdp.

2-5 minutes is a pretty aggressive cut-off time. Are you running through a corporate firewall?

[metalefty]

Yeah, I also think it is an expected behaviour but not an wanted behaviour. I would personally like to implement keepalive stuff if I could figure out what's happening MS to MS.

[matt335672]

Another possibility (a total guess on my part) is it could be network characteristic detection messages

The only way to be sure would be to run through a proxy and see what the messages are.

[shooreek]

Are you running through a corporate firewall?

Yes, the environment is pretty much corporate. It is site-to-site connection.

[matt335672]

The best I can offer you is to use TCP keepalive to keep the connection running.

This has come up a few times, so I've added a FAQ for it:-

https://github.com/neutrinolabs/xrdp/wiki/Tips-and-FAQ#how-can-i-prevent-connections-being-dropped-by-my-corporate-firewall

Give that a go and let us know it it works for you.

[shooreek]

The best I can offer you is to use TCP keepalive to keep the connection running.

I've tried to tune TCP keepalive on xrdp server and it working fine - I do not observe disconnections. Thanks a lot for advice!

The FAQ is good except for the values of TCP keepalive variables. If the aim is to keep connection alive, we probably need to set tcp_keepalive_time and tcp_keepalive_intvl variables to almost the same value, which should be less than minimal observed connection cut-off time. tcp_keepalive_time triggers keepalive for the connection and then is no longer used, while tcp_keepalive_intvl is the interval between subsequent keepalives which will have an impact on gateway/firewall - it shouldn't be too small. On my system I changed defaults 7200/75/9 to 75/75/9.

[matt335672]

Glad we've found a solution.

I'm not entirely in agreement with your settings (but if it works for you, stick with it). My understanding is the reason tcp_keepalive_intvl is low is to cater for the first packet of ANY probe sequence being lost (not just the first probe sequence). When an ACK is received for any probe, the value of tcp_keepalive_intvl is irrelevant. If however no ACK is received we want to send another pretty swiftly.

[shooreek]

Now I understand your reasoning.. And I think you're right. My considerations were elaborated for ideal network - I forgot about packet loss. tcp_keepalive_intvl should allow few retries/probes to be sent before connection cut-off to make the things reliable.

I hope that some day xrdp will be able to support connection by itself without the need in additional system/client tweaks. Unfortunately this will stop people from getting to know such exciting stuff like TCP keepalive :)

[matt335672]

There are a couple of ways we can manage this.

One way is to figure out what Win 11 to Win 11 traffic looks like, and implement some of those messages, at least partially.

Another way is to add code to xrdp to allow tcp_keepalive_time (and maybe the others) to be specified per-process. This is platform-specific. For Linux we can set TCP_KEEPIDLE / TCP_KEEPINTVL / TCP_KEEPCNT (see tcp(7)). FreeBSD appears to support the same options (see tcp(4p)). NetBSD also has these, but OpenBSD appears not to.

I'm going to keep this open, change the title and make this a feature request.