Windows rdp - breaks were intermittent, but disappeared when ping host -t from cmd, what is it for?

Question

Computer networks

An employee complained that he had periodic disconnections: the screen on the rdp connection froze, it was necessary to reconnect. I wanted to understand - it's physically torn something, or what kind of software is to blame.
I pinged him ping 192.168.0.x -t and told him to call when he chopped off.
I didn’t call, but the next day it broke again. I didn’t call because there were no breaks when ping requests worked, then the computer loaded, without breaks requests. I turned on the dreams, the cliffs disappeared. Chopped off - breaks appeared.
I set up a .bat for him with a connection to rdp and parallel ping -t in the background. Never had a break again.
Well set it and forget it. Two months later (yesterday) I again encountered this situation with another employee, when connected to a completely different computer.
Secrets of mankind for 1000: Someone knows what kind of game this is? Maybe you have come across such a thing, maybe it's a known bug / feature?

And yet, maybe somehow you can diagnose the cause of such screen fading?

Answer 1

After a long googling and fortune-telling on coffee grounds, after several months of testing the solution, I can clearly say the solution: all the problems went away after the UDP protocol was forcibly turned off on the client, leaving only TCP. I couldn’t find the reasons for the hangup (enikey skills didn’t allow), but the theory is as follows:
the user establishes a connection via RDP, and then packets are thrown back and forth via UDP, without checking the integrity and without sending packets that support the session (there are no “connection live” messages) , keepalive). Or somewhere along the way, someone loses connection due to the lack of keepalive packets, thinking that since there is no keepalive, then the connection is dead.
TCP always keepsalive, even if the RDP connection is closed, which is presumably why the connection does not break.
TCP only is enabled either through group policies (easily googled) or through the registry like this:
Use only TCP
Registry Hive HKEY_LOCAL_MACHINE
Registry Path SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Value Name SelectTransport
Value Type REG_DWORD
Value 1
There was a problem in the first place because I set up UDP myself, using this article from habr: https://habr.com/ru/post/501132/ , and in another place in my soul I don’t know why it appeared, but seven troubles is one answer.
ps Not everything is gold that the guide on Habré.

Answer 2

Cut on the client tcpdump/wireshark and look for connection failures by the time after an hour or two of work. Then see if there is anything strange in any of the logs at that moment. As an option, the network goes to sleep. As an option, the poppy address is lost, and ARP either gives a crooked address, or something else. If it is on Wi-Fi, as an option, the router decided to release the channel or somehow switch and the card is buggy, but this is not the case with constant traffic. If there is a VPN, as an option somewhere, the UDP session falls off on the router. There can be many problems.

Answer 3

You need a long check for 30 minutes, try to check with WinMtr, or ping with a large number of packets, long ping, also check the fragmentation of the MTU packets in the router and the provider, if they are different, then there will be packet fragmentation, this is (normal) but this can lead to an increase in ping and check if packet fragmentation works for you; all this can be done from the console with the ping command with the appropriate keys on windows; this is done like this ping yandex.ru -4 -l 65500

Answer 4

You can try disabling TCP receive window scaling. In Windows, see the current value:
netsh interface tcp show global
Here we are interested in the Receive Window Auto-Tuning Level parameter.
You can try to choose the right level, for example, try higlyrestricted, and if it doesn't help, then disable it:
netsh interface tcp set global autotuninglevel=disabled
After changing the settings, the computer should be restarted.
Linux has similar settings. In case of problems with RDP, I dug for several hours, but it turned out to be easier, put a tick in the network manager "Disable TCP window scaling".
PS In addition, the RDP client itself and the RDP server can do all sorts of baddies. I didn’t win that if there was no input for a long time (didn’t move the mouse or didn’t press the keyboard), then when you click / move the picture freezes, and reconnect goes. Although the connection was not hung up - if, for example, a video was playing there or some kind of software installation process was going on - everything was displayed and did not freeze. And all this is not counting the possibility of setting RDP parameters through policies (you can also do a lot of things there).