Freerdp: XFreeRdp disconnects after short periods of inactivity

[wtfrank]

[17:14:50:809] [6520:6521] [INFO][com.freerdp.client.common.cmdline] - loading channel rdpdr
[17:14:50:809] [6520:6521] [INFO][com.freerdp.client.common.cmdline] - loading channel rdpsnd
[17:14:50:809] [6520:6521] [INFO][com.freerdp.client.common.cmdline] - loading channel cliprdr
[17:14:51:463] [6520:6521] [INFO][com.freerdp.core.gateway.tsg] - TS Gateway Connection Success
[17:14:52:978] [6520:6522] [INFO][com.freerdp.channels.rdpdr.client] - Loading device service drive (static)
[17:15:10:546] [6520:6522] [INFO][com.freerdp.channels.rdpdr.client] - registered device #1: home (type=8 id=1)
[17:19:05:574] [6520:6521] [ERROR][com.freerdp.core.rdp] - rdp_check_fds: tsg_check_event_handles() - -1
[17:19:05:574] [6520:6521] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
[17:19:05:574] [6520:6521] [INFO][com.freerdp.client.x11] - Network disconnect!
[17:19:05:574] [6520:6521] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor

Launch command: client/X11/xfreerdp /g:gateway.xxx /v:xxx /d:xxx /u:xxx /p:xxx +clipboard /w:1600 /h:1000 +home-drive

This occurs with commit bfdf025e88bdd2961bd89b6bc24e6a0bda368ed7 but it has been happening since last year.

Let me know if there are any logs that it would be useful for me to gather.

[wtfrank]

Nice one, this solves the problem for me.

I initially doubled the value to 8000, but I still got disconnected quite quickly. I doubled it again to 16,000 and my remote desktop session has stayed connected for hours. This is a personal best!

[bmiklautz]

@wtfrank can you tell me what type of connection setup are you using?

[wtfrank]

Connecting from Linux to Windows servers with a gateway server. The command I'm using to connect is: "xfreerdp /g:gateway.xxx /v:ts-xxx.xxx /d:DDD /u:UUU /p:PPP /workarea +clipboard +home-drive"

Is this the info you were after @bmiklautz?

[bmiklautz]

@wtfrank I was more thinking about your network connection. Is this gsm/ethernet/..?

[wtfrank]

@bmiklautz ethernet via business DSL over the internet to the datacentre.

There aren't any noticeable problems with the connection - steady ping, no dropped packets. Maybe there are occasional glitches though?

edit: rare packet loss observed. Perhaps that's what's leading to this.

[thomaspaulb]

I have this problem also, using the command:

xfreerdp /gdi:sw /compression /f -decorations /size:1280x720 \
  -grab-keyboard -network: /u:xxx /p:xxx +clipboard \
  /drive:home,/home/myuser/share /v:myserver:myport

I tried increasing the TCP_USER_TIMEOUT to 60000, but this just resulted in my session hanging for a longer time before disconnecting with "freerdp_check_fds() failed - 0" and "Network disconnect" as stated above.

Removing the drive redirections lets my session live longer, but I haven't tested enough to be sure if this solves the issue.

[wtfrank]

Yeah after further testing with a 60s timeout, I still get disconnected frequently, so changing the timeout isn't a complete solution to this issue.

[thomaspaulb]

More information from me: I am using a steady and fast network connection, the latest git master version of XFreeRDP built with "make", I am connecting from Linux Mint 17 64 bit to Windows Server 2012 R2, and I am having the problem that the session hangs before disconnecting. After hanging, subsequent keyboard and mouse output does not arrive remotely anymore. Hanging occurs randomly, sometimes after a few seconds, sometimes after a few minutes, after inactivity but also during clicking around in programs.

[thomaspaulb]

Correction... the cable network connection that I used was not stable. Other programs also suffered disconnections. Probably an issue with my network card drivers. Now using Wifi and is going better. I did however see the problem on other Wifi connections before, so will investigate more.

[thomaspaulb]

Did not see the problem anymore over WiFi, so I'm blaming my cable network card and its packet loss.

[TheOracle22]

This may be a dumb question, but where is tcp.c file located on my system? I tried to do a find and got back no results?

[thomaspaulb]

It's in the source code... you download the source code and then you have to recompile XFreeRDP. Normal systems have the already-compiled binary version of XFreeRDP installed. But I think the modification will not solve your problem... what problem are you having?

[TheOracle22]

When I connect to Windows 10 it will disconnect me anywhere from 30 seconds to 10 minutes. I've experienced this through Remmina which I believe uses this library and also directly through the command line xfreerdp.

[thomaspaulb]

Well most OS'es like Ubuntu package a very old version of XFreeRDP. The first thing you can do is to deinstall the old XFreeRDP, then download the newest GitHub version, compile it using these instructions:

https://github.com/FreeRDP/FreeRDP/wiki/Compilation

And then connect using the new XFreeRDP. If you are still having the same issues, then the problem can be investigated further.

[bmiklautz]

@antiflu @TheOracle22 either compile yourself or you try our nightly builds when available for your system https://github.com/FreeRDP/FreeRDP/wiki/PreBuilds

[TheOracle22]

Thank you very much! I will give your suggestions a try.

[TheOracle22]

I downloaded the latest nightly build today and it still times out. I ran xfreerdp from /opt/freerdp-nightly/bin. I am running over a VPN connection for work. I'm not sure if that makes a difference or not.
This is the error I get:

[10:33:49:028] [5030:5031] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 110: Connection timed out
[10:33:49:028] [5030:5031] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
[10:33:49:028] [5030:5031] [INFO][com.freerdp.client.x11] - Network disconnect!
[10:33:49:028] [5030:5031] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor

Thanks

[thomaspaulb]

Personally I had a similar problem and spent a lot of time debugging, when in the end it turned out to be my unstable network connection. It could also be your network card / drivers acting up. So I would advise you to do some "elimination testing": try another WiFi spot, try a cable connection instead of Wifi, try the same nightly build but on another laptop, try (if you can) the same connection but directly at the office without the VPN. Also try to connect to another Windows computer _somewhere_ on the internet. Then with that information come back here, and we can exclude the possibility of packet loss in your connection being the problem. Then also post the exact command line options that you are using to connect, and the conditions under which the disconnect occurs (is it random, or is there a certain pattern like.. always after 2 minutes, or always after you click a certain program).

[BethAr]

I'm getting the same problem as well, connecting to a Windows machine, when I leave the connection idle.
As long as I keep using it, it doesn't disconnect.

Is there any alternative for solving this without recompilation?

[akallabeth]

@bethar without knowing which version you use it is hard to tell, but there are always the nightly builds.

[wtfrank]

The TCP timeout change from earlier didn't seem to help after all - it maybe improved a bit but I still get disconnects. I just got the latest build today, and added some debug logging to find out where exactly the problem is happening. It seems to be that the openssl connection is closed for some reason.

[18:20:16:363] [14726:14727] [ERROR][com.freerdp.core.gateway.http] - BIO_should_retry failure (status=-1)
[18:20:16:363] [14726:14727] [ERROR][com.freerdp.core.gateway.rpc] - http_response_recv failure (2)
[18:20:16:363] [14726:14727] [DEBUG][com.freerdp.core.gateway.tsg] - rpc_client_in_channel_recv returned -1
[18:20:16:363] [14726:14727] [ERROR][com.freerdp.core.rdp] - rdp_check_fds: tsg_check_event_handles() - -1
[18:20:16:363] [14726:14727] [DEBUG][com.freerdp.core] - rdp_check_fds() - -1
[18:20:16:363] [14726:14727] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
[18:20:16:363] [14726:14727] [INFO][com.freerdp.client.x11] - Network disconnect!

[akallabeth]

@wtfrank Looks like some gateway related issue, could you use transport_bio_error_log to get the BIO error details?

[wtfrank]

[12:19:30:086] [17309:17310] [ERROR][com.freerdp.core.gateway.http] - BIO_should_retry returned a system error 104: Connection reset by peer

[wtfrank]

I am able to remain connected for hours when I connect from the windows remote desktop client from another laptop on the same internet connection, so I hypothesise that the connection is actively closed by the server because of something it doesn't like about what FreeRDP sends (or something that is missing).

In order to test this hypothesis, I attempted an active close by logging on two clients simultaneously which lead to the following logs:

[15:43:31:705] [13300:13301] [DEBUG][com.freerdp.core.rdp] - recv Set Error Info Data PDU (0x2F), length: 22
[15:43:31:705] [13300:13301] [INFO][com.freerdp.core] - ERRINFO_DISCONNECTED_BY_OTHER_CONNECTION (0x00000005):Another user connected to the server, forcing the disconnection of the current connection.
[15:43:31:723] [13300:13301] [DEBUG][com.freerdp.core.rdp] - DisconnectProviderUltimatum: reason: 1
[15:43:31:725] [13300:13301] [DEBUG][com.freerdp.channels.rdpgfx.client] - Terminated

These logs are different from the ones I am seeing when FreeRDP connection randomly drops. In fact I wonder whether it is the gateway server randomly dropping the connection, while the double logon disconnection is initiated by the remote desktop server which would explain the difference.

Are there any keep-alive type messages in the RDP protocol? I often find that the FreeRDP connection drops if I leave it open and work in another (local) window.

[lumm]

I have the same question too, but I think I have reproduce the question. Here is my reproducing process。
You have computer A and computer B，which are connected the same route。For instance, you use computer A to connect rdp server(not computer B rdp server)，then you set compute B mac address with computer A. After a few seconds, you disconnect computer B network, and reconnect, and repeat three or four times, computer A will disconnect rdp connection.

[pgconlin]

I have an additional datapoint which will hopefully be useful: I recently switched from CentOS 7 to Fedora 24 on my desktop (no change in hardware), while continuing to connect to the same RDP server (win2k3 oops, I meant win2k8) over the same connection (firewall-to-firewall IPSEC over public internet, all wired, no wifi). The xfreerdp client on CentOS 7 remained connected to the RDP server indefinitely--only had a disconnect when the actual physical link was down. Now on Fedora, I'm having this issue of the xfreerdp client (much newer--had to redo all my bash aliases to use the new option/switch format) disconnecting all the time. Admittedly this could be a kernel/driver issue and not an xfreerdp client issue, but I thought I'd mention it as an A/B test case.

[wtfrank]

Any chance you can find out the versions of freerdp that you used in CentOS 7 and Fedora 24?

[pgconlin]

Yeah sorry about that.

CentOS 7: freerdp-1.0.2-5.el7_1.1.src.rpm
Fedora 24: freerdp-2:2.0.0-5.git.b02943a.fc24

Patrick

On 07/01/2016 12:42 PM, wtfrank wrote:

Any chance you can find out the versions of freerdp that you used in
CentOS 7 and Fedora 24?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/FreeRDP/FreeRDP/issues/2802#issuecomment-230031988,
or mute the thread
https://github.com/notifications/unsubscribe/AGSQPBGLsvNwrL0FfJx_4B45sSdGTin3ks5qRW2agaJpZM4FehcH.

[pgconlin]

Also, in my case the message at disconnect is:

[ERROR][com.freerdp.core] - ERRINFO_LOGOFF_BY_USER (0x0000000C):The disconnection was initiated by the user logging off his or her session on the server.
[ERROR][com.freerdp.core.rdp] - DisconnectProviderUltimatum: reason: 3

But of course I haven't logged off, and the timeout settings on the server are the same as they were when I was using the CentOS version of xfreerdp.

[akallabeth]

@pgconlin Your error messages look like they were actualy initiated by the server and are not caused by the TCP issue mentioned above. (See libfreerdp/core/rdp.c:336 and following)

[pgconlin]

Right, this is why I'm posting here. Keep in mind that this is FreeRDP
reporting this reason for disconnection, not the server. I believe this
to be in error.

I am the admin for the server I'm connecting to and have complete
control over the RDP settings. Disconnected, Active, and Idle session
limits are all set to Never.

As I mentioned previously, the version of FreeRDP packaged for CentOS 7
(freerdp-1.0.2-5.el7_1.1) did not disconnect like this, ever.

Interesting to note that the comment ~at libfreerdp/core/rdp.c:336
specifically states that a workaround was added to deal with win2k8 R2
(my server's OS) RDP's failure to report PDU.

I'm under the impression that this version of FreeRDP is
_misinterpreting something else_ as being a user logoff, but I don't
know what that would be. Perhaps the workaround is generating
false-positives for user logoff events?

On 07/04/2016 02:50 AM, akallabeth wrote:

@pgconlin https://github.com/pgconlin Your error messages look like
they were actualy initiated by the server and are not caused by the TCP
issue mentioned above. (See |libfreerdp/core/rdp.c:336| and following)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FreeRDP/FreeRDP/issues/2802#issuecomment-230251438,
or mute the thread
https://github.com/notifications/unsubscribe/AGSQPA8OItL2hdmHgKX0Dd8NgMvw6J9eks5qSNdlgaJpZM4FehcH.

[bmiklautz]

@pgconlin at the line you referring to in rdp.c the connection is already disconnecting the code is an additional approach to figure out the reason for the disconnect.
From the information we have it looks like you are actively disconnected from the server but it's not clear why (it does send a disconnect provider ultimatum)
Is there anything useful you can find in the server logs?

[mattonm]

For anyone still struggling with this, I was using a 2008 R2 RDS Gateway but I recently built a 2012 RDS Gateway. Once I started using the 2012 RDS Gateway, the very frequent disconnects stopped. When I have a moment, I'll check if it's a configuration issue on the 2008 gateway.
Cheers,

[pgconlin]

woohoo!  Still having the issue and very interested to hear what you find out.

On Tue, Mar 14, 2017 at 11:15 AM -0700, "mattonm" [e-mail] wrote:

For anyone still struggling with this, I was using a 2008 R2 RDS Gateway but I recently built a 2012 RDS Gateway. Once I started using the 2012 RDS Gateway, the very frequent disconnects stopped. When I have a moment, I'll check if it's a configuration issue on the 2008 gateway.

Cheers,

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[pjc27]

I need to incrased TCP _USER_TIMEOUT to stop my rdp from random dropouts.
Can someone point me to a guide to recompile xfreerdp ? Help.

[HelterBelter]

@pjc27:
Did you see this ?
https://github.com/FreeRDP/FreeRDP/wiki/Compilation

[lewisdonofrio]

What do I need to do to track down these https://apaste.info/Igic keep in context I have two sessions to two machines (powerpc g5 at home with dual displays connected like left monitor to left desktop at work and right monitor to right desktop at work (the two desktop's at work are both W10 desktop's on my desk and both plugged into corp network) https://1drv.ms/f/s!AsBlZbBf72iNoMAplO_E57h6t15TmA (skip onedrive unneeded logon) ok why it once side loses connection to one side but never both at same time (unless vpn goes down) fwiw hwinfo = https://apaste.info/oa5J and fulldmesg = https://apaste.info/TyDD I'm wanting to troubleshoot if possible, oh I'm using "This is FreeRDP version 2.0.0-dev2 (bab902f)" fwiw compiled using these steps https://github.com/FreeRDP/Remmina/wiki/Compile-on-Ubuntu-16.04 only deviated when it came to sse2 because I do not have that on the powerpc's so I just turn that off when I compile "cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_SSE2=OFF -DWITH_CUPS=on -DWITH_WAYLAND=off -DWITH_PULSE=on -DCMAKE_INSTALL_PREFIX:PATH=/opt/remmina_devel/freerdp ." then make && sudo make install

[akallabeth]

@lewisdonofrio looks like you ran into some kind of timeout (in the transport/SSL layer). Does enabling +heartbeat solve that for you?

[mnowaksuse]

We run FreeRDP like this:

xfreerdp /u:Administrator /p:'pw' /v:hostname /cert-ignore /vmconnect:GUID /f /log-level:DEBUG

and sometimes the connection is dropped after a while:

[12:48:17:107] [3423:3425] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[12:48:17:107] [3423:3425] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[12:48:17:109] [3423:3425] [INFO][com.freerdp.client.x11] - Property 240 does not exist
[12:48:17:109] [3423:3425] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[12:48:17:110] [3423:3425] [DEBUG][com.freerdp.client.x11] - Pointer device: 6
[12:48:17:113] [3423:3425] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: FALSE
[12:48:17:113] [3423:3425] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[12:48:17:113] [3423:3425] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[12:48:17:113] [3423:3425] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[12:48:17:113] [3423:3425] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[12:48:17:113] [3423:3425] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[12:48:17:113] [3423:3425] [DEBUG][com.freerdp.core.nego] - Security Layer Negotiation is disabled
[12:48:17:113] [3423:3425] [DEBUG][com.freerdp.core.nego] - Sending preconnection PDU
[12:48:17:128] [3423:3425] [DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[12:48:17:128] [3423:3425] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_NLA
[12:48:17:339] [3423:3425] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[12:48:17:339] [3423:3425] [DEBUG][com.freerdp.core.nla] - nla_client_init 314 : packageName=Negotiate ; cbMaxToken=12256
[12:48:17:339] [3423:3425] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token
...
[12:49:47:617] [3423:3425] [DEBUG][com.freerdp.core.update] - Cache Bitmap V2 (Compressed) Secondary Drawing Order (0x05)
[12:49:47:617] [3423:3425] [DEBUG][com.freerdp.core.update] - MemBlt Primary Drawing Order (0x0000000D)
[12:49:47:617] [3423:3425] [DEBUG][com.freerdp.core.update] - Frame Marker Alternate Secondary Drawing Order (0x0D)
[12:49:47:662] [3423:3425] [DEBUG][com.freerdp.core.rdp] - recv Set Error Info Data PDU (0x2F), length: 22
[12:49:47:662] [3423:3425] [INFO][com.freerdp.core] - ERRINFO_GRAPHICS_SUBSYSTEM_FAILED (0x0000112F):The server-side graphics subsystem is in an error state and unable to continue graphics encoding.
[12:49:47:663] [3423:3425] [DEBUG][com.freerdp.core.transport] - transport_check_fds: transport_read_pdu() - -1
[12:49:47:663] [3423:3425] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
[12:49:47:663] [3423:3425] [DEBUG][com.freerdp.core] - rdp_check_fds() - -1

Client: FreeRDP 2.0.0 RC1 from https://build.opensuse.org/package/show/X11:RemoteDesktop/freerdp.
Host: Windows Server 2012 R2 with Hyper-V with all updates.

Might +heartbeat help here?

[akallabeth]

@mnowaksuse This is a server side error and has nothing to do with freerdp ('Error Info Data PDU' means the server tells the client something is wrong)

[count0-krsk]

Same problem, after migrating from Lubuntu 12.04.2 x86 to Lubuntu 14.04.5 x64.
Version I used accept switches "--", new version wants "/"
Router and ISP's same, Servers (2x on same ISP) - 2008R2 x64 with updates, without gateway and automatic disconnect (try to set 12-36 hours, no helps).
I try set security policy on server to "check connection", no helps:

Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\ Connections\
Keep-Alive Connections Enabled
Keep-Alive interval: 1

Connection drops after minute or so, then window minimized. +heartbeat not helps.
Find analog problem with Windows client:
https://superuser.com/questions/1144853/how-do-i-keep-an-rdp-session-alive-from-the-client-side
It has option in registry:

Another option is to edit this registry value:
HKEY_LOCAL_MACHINE
Software => Microsoft => Terminal Server Client
DWORD
RemoteDesktop_SuppressWhenMinimized
Set the value to 2

I know, then bmp caching is enabled, windows client stop updating the screen, and connection losses after some time. Then window restored, it show "Reconnecting 1of 20" and successfully reconnects without registry tweaks. Why xfreerdp don't do so and just exit?
--no-bmp-cache --no-glyph-cache - no helps.
/log-level:DEBUG don't show debug info, just usual "Failed to check FreeRDP file descriptor" on disconnect.
Time to disconnect - 1 minute and several seconds. I try open youtube on server to prevent bmp caching - no helps.
In Wireshark I see after connect many:
-PSH, ACK
-ACK
-FIN, ACK (from my PC to server)
-ACK
-RST, ACK
So, it's xfreerdp closes connection. And it does not send packets when minimized!!! I see only 1 keep-alive in one trace, and no keep-alive in another.

---

Have some happiness: I say that set "Keep-Alive Connections Enabled, 1minute" in windows, but read that it not work until ALL parameters in "Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits" are set. Also I set "Disable Clipboard redirection" to False, and "Maximum desktop depth" to 16 bit, but think it's not matter.
So I do this, run gpupdate /force, and all fine now. I have 1 hour or so without disconnect. My PC sends keep-alive packets and some PSH-ACK data <> servers then minimized. Also see "Continuation", protocol type PCKT.

So, why this happen? Server MUST push xfreerdp to work correctly? It's bad things, mans. Not all have rights to group policy on server. You broke something between version 1.0.2 and 1.1.0-beta1 (git n/a).

keys that I use now to connect:
xfreerdp -g 1650x970 --plugin cliprdr --ignore-certificate -u xxx1 --no-bmp-cache +auto-reconnect --no-glyph-cache -T Main 1.1.1.1

[akallabeth]

@count0-krsk Your assumptions are flawed. Your own example with mstsc displaying Reconnecting 1 of 20 shows that it is the SERVER that discards the connection and the client needs to reconnect when that happens.
So, I'd suggest you do the following:

• Convert your command line to the new syntax, the old one is deprecated (will be dropped soon and is not really tested)
• Try our nightly builds, there has been a merge fixing autoreconnect issues.

[count0-krsk]

LOL, your answer like some ISP's support: "please update *, if problem still exists, it's on your side" )))
Man, I see with my eyes, that YOUR soft don't send packets, when minimized. Did you test it, now? Or you want just say "don't boring me, I'm busy!" ? I update it, ok, but later. This problem is old, and Ubuntu version is old. Why you don't post last stable version in Ubuntu repo? Communication problems? I see, I see )))

[lewisdonofrio]

I use freerdp daily and it's totally sending updates even when minimized....

[count0-krsk]

That version?

[lewisdonofrio]

This is FreeRDP version 2.0.0-dev2 (f8baeb7)

[akallabeth]

@count0-krsk Read again.

1. You have a special server configuration discarding idle connections.
2. We have a bug that is only fixed in more recent versions (autoreconnect).
3. Ubuntu is shipping old versions which have known bugs. complain there if you want to use that versions, we have limited power over what they include.

[count0-krsk]

OK, thanks.
How I can talk to ubuntu maintainers, for updating their versions, or you have ppa, for stable releases?
Manual updating on many PC's is hard.

[akallabeth]

@count0-krsk we only provide source releases and the nightly builds. as for issues, there are the issue trackers for packages in ubuntu where you can file a bug. (your mileage may vary as freerdp is in universe)
the remmina ppa might help you, they also ship quite a recent freerdp they use as backend.

[lewisdonofrio]

@count0-krsk - I think compiling and scp'ing out to your host is best you're going to get right now (if you need it in a hurry is not then prod the maintainers of that package/repo and wait till it gets updated.)

[ppokhriyal]

Hi,

Please try these flags '+auto-reconnect' 'auto-reconnect-max-retries:0'

[akallabeth]

#4710 should have fixed the reconnection issue.
Gateway currently working after some pr have been merged, please reopen / create a new issue if there are still issues with gateway connections.