RDP session is dropped from time to time, reproducible situation. #723

Closed
fuziko opened this Issue Jan 14, 2016 · 30 comments

Projects

None yet

6 participants

@fuziko
fuziko commented Jan 14, 2016

Hello there!

  1. Sorry for my English :)
  2. Trouble that my RDP-session is periodically dropped and i suppose course Reminna or FreeRDP got some packet that can't be processed without error that affect remote connection to remote server.
    It reproducible situation and i can create some debug logs if you say how to enable it.
    Also i can enable debug logs on my destination remote managed PC for full view and of course can record RDP-traffic between this two hosts.
    Will be glad any help with that issue.
@giox069 giox069 self-assigned this Jan 17, 2016
@giox069
Contributor
giox069 commented Jan 17, 2016

@fuziko @bw1945: Yes it happens also to me. I started a new code branch called "reconnect", and I hope in a week or two to have an automatic reconnection method supported (as the microsoft client does under windows).
The disconnection problems seems to be inside freerdp. Could someone test

xfreerdp /v:hostname /u:usermame /d:domainame

and see if disconnect as frequently as Remmina ?

@luca-e
luca-e commented Jan 17, 2016

Hi Giovanni,
I had the same issue. According to the first tests, this freerdp patch seems to fix it (Linux Mint 17.3, freerdp and remmina from remmina-next repository):

bmiklautz/FreeRDP@81e42c7

Tomorrow I'll do more extensive testing and let you know.

@giox069
Contributor
giox069 commented Jan 17, 2016

@luca-e thank you for pointing to that patch.
Raising from 4 to 60 seconds TCP_USER_TIMEOUT will be a good solution for WAN links, where you can experience connectivity loss more frequenlty than in LAN.
But there are some unclear things here:

  1. my remmina and freerdp detects a timeout after 30s, not 4s. I think the current timeout is 30s because the TCP_USER_TIMEOUT macro is not defined. 30s is enough to recover all disconnection I have seen.
  2. In my tests, I had 3-4 RDP connection opened to the same remote LAN. Then one of the 4 connection drops. The other three still active and working, because I'm working inside one of them. I don't think my disconnections were caused by a socket timeout [which means: loss of ACK packet in TCP connection] :(

@fuziko @bw1945: do you remember if your connection loss was in local LAN or to a remote WAN host ?

@bw1945
bw1945 commented Jan 17, 2016

10.xx.xx.xx remote WAN host.

bw@BwUb:$ xfreerdp /v:10.xx.xx.xx:3389 /u:bvv@xx.net /d:xx.net /monitors:1
/f
[14:31:34:363] [8056:8057] [WARN][com.freerdp.core.nego] - Error:
SSL_NOT_ALLOWED_BY_SERVER
[14:31:34:473] [8056:8057] [WARN][com.freerdp.core.nego] - Error:
SSL_NOT_ALLOWED_BY_SERVER
[14:36:17:753] [8056:8057] [ERROR][com.freerdp.core] -
ERRINFO_DECRYPT_FAILED (0x00001192):(a) Decryption using Standard RDP
Security mechanisms (section 5.3.6) failed.
(b) Session key creation using Standard RDP Security mechanisms (section
5.3.5) failed.
[14:36:17:753] [8056:8057] [ERROR][com.freerdp.core] - freerdp_check_fds()
failed - 0
[14:36:17:753] [8056:8057] [ERROR][com.freerdp.client.x11] - Failed to
check FreeRDP file descriptor
bw@BwUb:
$ xfreerdp /v:10.xx.xx.xx:3389 /u:bvv@xx.net /d:xx.net /d:zemz.net
/monitors:1 /f
[14:36:40:606] [8271:8272] [WARN][com.freerdp.core.nego] - Error:
SSL_NOT_ALLOWED_BY_SERVER
[14:36:40:687] [8271:8272] [WARN][com.freerdp.core.nego] - Error:
SSL_NOT_ALLOWED_BY_SERVER
[14:48:13:913] [8271:8272] [ERROR][com.freerdp.core] -
ERRINFO_DECRYPT_FAILED (0x00001192):(a) Decryption using Standard RDP
Security mechanisms (section 5.3.6) failed.
(b) Session key creation using Standard RDP Security mechanisms (section
5.3.5) failed.
[14:48:13:914] [8271:8272] [ERROR][com.freerdp.core] - freerdp_check_fds()
failed - 0
[14:48:13:914] [8271:8272] [ERROR][com.freerdp.client.x11] - Failed to
check FreeRDP file descriptor

bw@BwUb:~$ xfreerdp /v:10.xx.xx.xx:3389 /u:bvv@xx.net /d:xx.net /monitors:1
/f
...

If I can add something, please tell me what and how :)
Thank you!

2016-01-17 15:18 GMT+02:00 Giovanni Panozzo notifications@github.com:

@luca-e https://github.com/luca-e thank you for pointing to that patch.
Raising from 4 to 60 seconds TCP_USER_TIMEOUT will be a good solution for
WAN links, where you can experience connectivity loss more frequenlty than
in LAN.
But there are some unclear things here:

  1. my remmina and freerdp detects a timeout after 30s, not 4s. I think the
    current timeout is 30s because the TCP_USER_TIMEOUT macro is not defined.
    30s is enough to recover all disconnection I have seen.
  2. In my tests, I had 3-4 RDP connection opened to the same remote LAN.
    Then one of the 4 connection drops. The other three still active and
    working, because I'm working inside one of them. I don't think my
    disconnections were caused by a socket timeout [which means: loss of ACK
    packet in TCP connection] :(

@fuziko https://github.com/fuziko @bw1945 https://github.com/bw1945:
do you remember if your connection loss was in local LAN or to a remote WAN
host ?


Reply to this email directly or view it on GitHub
#723 (comment).

@bw1945
bw1945 commented Jan 18, 2016

We continue to fall ... :(
Thank you!

2016-01-17 15:43 GMT+02:00 Валентин Бочаров bw1945@gmail.com:

10.xx.xx.xx remote WAN host.

bw@BwUb:$ xfreerdp /v:10.xx.xx.xx:3389 /u:bvv@xx.net /d:xx.net
/monitors:1 /f
[14:31:34:363] [8056:8057] [WARN][com.freerdp.core.nego] - Error:
SSL_NOT_ALLOWED_BY_SERVER
[14:31:34:473] [8056:8057] [WARN][com.freerdp.core.nego] - Error:
SSL_NOT_ALLOWED_BY_SERVER
[14:36:17:753] [8056:8057] [ERROR][com.freerdp.core] -
ERRINFO_DECRYPT_FAILED (0x00001192):(a) Decryption using Standard RDP
Security mechanisms (section 5.3.6) failed.
(b) Session key creation using Standard RDP Security mechanisms (section
5.3.5) failed.
[14:36:17:753] [8056:8057] [ERROR][com.freerdp.core] - freerdp_check_fds()
failed - 0
[14:36:17:753] [8056:8057] [ERROR][com.freerdp.client.x11] - Failed to
check FreeRDP file descriptor
bw@BwUb:
$ xfreerdp /v:10.xx.xx.xx:3389 /u:bvv@xx.net /d:xx.net /d:
zemz.net /monitors:1 /f
[14:36:40:606] [8271:8272] [WARN][com.freerdp.core.nego] - Error:
SSL_NOT_ALLOWED_BY_SERVER
[14:36:40:687] [8271:8272] [WARN][com.freerdp.core.nego] - Error:
SSL_NOT_ALLOWED_BY_SERVER
[14:48:13:913] [8271:8272] [ERROR][com.freerdp.core] -
ERRINFO_DECRYPT_FAILED (0x00001192):(a) Decryption using Standard RDP
Security mechanisms (section 5.3.6) failed.
(b) Session key creation using Standard RDP Security mechanisms (section
5.3.5) failed.
[14:48:13:914] [8271:8272] [ERROR][com.freerdp.core] - freerdp_check_fds()
failed - 0
[14:48:13:914] [8271:8272] [ERROR][com.freerdp.client.x11] - Failed to
check FreeRDP file descriptor

bw@BwUb:~$ xfreerdp /v:10.xx.xx.xx:3389 /u:bvv@xx.net /d:xx.net
/monitors:1 /f
...

If I can add something, please tell me what and how :)
Thank you!

2016-01-17 15:18 GMT+02:00 Giovanni Panozzo notifications@github.com:

@luca-e https://github.com/luca-e thank you for pointing to that patch.
Raising from 4 to 60 seconds TCP_USER_TIMEOUT will be a good solution for
WAN links, where you can experience connectivity loss more frequenlty than
in LAN.
But there are some unclear things here:

  1. my remmina and freerdp detects a timeout after 30s, not 4s. I think
    the current timeout is 30s because the TCP_USER_TIMEOUT macro is not
    defined. 30s is enough to recover all disconnection I have seen.
  2. In my tests, I had 3-4 RDP connection opened to the same remote LAN.
    Then one of the 4 connection drops. The other three still active and
    working, because I'm working inside one of them. I don't think my
    disconnections were caused by a socket timeout [which means: loss of ACK
    packet in TCP connection] :(

@fuziko https://github.com/fuziko @bw1945 https://github.com/bw1945:
do you remember if your connection loss was in local LAN or to a remote WAN
host ?


Reply to this email directly or view it on GitHub
#723 (comment).

@luca-e
luca-e commented Jan 18, 2016

@giox069 Maybe there are multiple causes under this issue.
Anyway in WAN environments the above patch seems to be a huge improvement. Today I tested it on 6 different clients connecting to 2 different servers (all WAN connections, as you correctly pointed out). Before the patch all the clients were disconnecting every 2-3 minutes. After the patch we saw no disconnections in 8 hours.
@bw1945 Did you try applying the patch?

@bw1945
bw1945 commented Jan 18, 2016

Unfortunately I do not know ... :(

2016-01-18 19:21 GMT+02:00 luca-e notifications@github.com:

@giox069 https://github.com/giox069 Maybe there are multiple causes
under this issue.
Anyway in WAN environments the above patch seems to be a huge improvement.
Today I tested it on 6 different clients connecting to 2 different servers
(all WAN connections, as you correctly pointed out). Before the patch all
the clients were disconnecting every 2-3 minutes. After the patch we saw no
disconnections in 8 hours.
@bw1945 https://github.com/bw1945 Did you try applying the patch?


Reply to this email directly or view it on GitHub
#723 (comment).

@bw1945
bw1945 commented Jan 18, 2016

Tell me please, is there any explanation for that a few months ago,
connection problems were not?
Thank you.

... and will learn how to apply the patch :)

2016-01-18 19:52 GMT+02:00 Валентин Бочаров bw1945@gmail.com:

Unfortunately I do not know ... :(

2016-01-18 19:21 GMT+02:00 luca-e notifications@github.com:

@giox069 https://github.com/giox069 Maybe there are multiple causes
under this issue.
Anyway in WAN environments the above patch seems to be a huge
improvement. Today I tested it on 6 different clients connecting to 2
different servers (all WAN connections, as you correctly pointed out).
Before the patch all the clients were disconnecting every 2-3 minutes.
After the patch we saw no disconnections in 8 hours.
@bw1945 https://github.com/bw1945 Did you try applying the patch?


Reply to this email directly or view it on GitHub
#723 (comment).

@luca-e
luca-e commented Jan 18, 2016

@bw1945 Assuming you are using Remmina Next repository, you can follow this procedure to create and install the patched .deb
Disclaimer: My experience with Debian packages is near zero! So I would gladly accept any hints from more experienced users.

mkdir freerdp-patched
cd freerdp-patched
apt-get source libfreerdp-plugins-standard
sudo apt-get install build-essential dpkg-dev
sudo apt-get build-dep libfreerdp-plugins-standard
cd freerdp-1.2.0~git20151218+dfsg/
wget --no-check-certificate https://github.com/bmiklautz/FreeRDP/commit/81e42c7ed0e13e39c95ce02d08000dd460aebdca.patch
patch -p1 <81e42c7ed0e13e39c95ce02d08000dd460aebdca.patch 
dpkg-source --commit
dpkg-buildpackage -uc -us
cd ..
sudo dpkg -i libfreerdp1_1.2.0~git20151218+dfsg-0trusty1_amd64.deb 
sudo dpkg -i libfreerdp-plugins-standard_1.2.0~git20151218+dfsg-0trusty1_amd64.deb 
@antenore
Member

👍 kudos for this discussion to everybody! Really cool!

@bw1945
bw1945 commented Jan 19, 2016

Many thanks for your help and attention!
I began implementation of your instructions and received an update Remmina.
Performed. But how do I deal with your updates after installing the patch?
Thank you.

2016-01-18 23:03 GMT+02:00 Antenore Gatta notifications@github.com:

[image: 👍] kudos for this discussion to everybody! Really cool!


Reply to this email directly or view it on GitHub
#723 (comment).

@luca-e
luca-e commented Jan 19, 2016

@bw1945 If you confirm that the patch fixes your issue, I guess we can ask @dktrkranz (who is managing freerdp packages on remmina-next repo) to include the patch in the next freerdp updates (it's a really simple patch and the chance of regressions are almost zero), but obviously this is @antenore 's call.

@giox069
Contributor
giox069 commented Jan 19, 2016

I don't think rising a timeout will be the right solution: the user will wait with a frozen desktop for more than 30 seconds without understanding what's happening.
You can patch your local copy for higher timeout, but for the official PPA it will be wiser to wait for the full reconnect procedure (which will include warning the user of connectivity loss).

@giox069
Contributor
giox069 commented Jan 19, 2016

And in the meanwhile, @bw1945, check if you can persist across disconnection with the internal freerdp support for autoreconnection:

xfreerdp /v:10.xx.xx.xx:3389 /u:bvv@xx.net /d:xx.net /monitors:1 +auto-reconnect

In these days I'm deeply investigating in

  1. Disconnection causes. I'm digging inside the freerdp code to find out where the error is detected to generate better logging, but it's hard to find, because sometimes I have no disconnections for hours.
  2. Making remmina to reconnect, as "+auto-reconnect" does.

But... It will take some time.

@bw1945
bw1945 commented Jan 19, 2016

Indeed, today reconnection takes 3-5 seconds, almost no effect on the
efficiency of my work. Increasing the time to 30 seconds - unacceptable at
the frequency with which the discontinuities are now.

2016-01-19 12:45 GMT+02:00 Giovanni Panozzo notifications@github.com:

I don't think rising a timeout will be the right solution: the user will
wait with a frozen desktop for more than 30 seconds without understanding
what's happening.
You can patch your local copy for higher timeout, but for the official PPA
it will be wiser to wait for the full reconnect procedure (which will
include warning the user of connectivity loss).


Reply to this email directly or view it on GitHub
#723 (comment).

@luca-e
luca-e commented Jan 19, 2016

@giox069 As you say, raising the timeout value is a rather controversial choice (see FreeRDP/FreeRDP#2936 ). Freerdp is going for a 16 secs timeout which can be a good tradeoff ( FreeRDP/FreeRDP#3015 ). Anyway having Remmina autoreconnect would be great.

@bw1945
bw1945 commented Jan 19, 2016

@giox069 today do not work remotely.
Run the command to test:
xfreerdp /v:10.xx.xx.xx:3389 /u:bvv@xx.net /d:xx.net / monitors: 1 + auto-reconnect
Behaves well :)
The connection is restored quickly.

Sorry for the repetition, but will not help if you analyze WHY the problem of frequent disconnection appeared not so long ago?

@luca-e seems version of the package does not correspond to the patch:
bw@BwUb:~/freerdp-patched$ apt-get source libfreerdp-plugins-standard
...
dpkg-source: инфо: извлечение freerdp в freerdp-1.0.2
dpkg-source: инфо: распаковывается freerdp_1.0.2.orig.tar.gz
dpkg-source: инфо: распаковывается freerdp_1.0.2-2ubuntu1.debian.tar.gz

...

bw@BwUb:/freerdp-patched/freerdp-1.2.0git20151218+dfsg$ wget --no-check-certificate https://github.com/bmiklautz/FreeRDP/commit/81e42c7ed0e13e39c95ce02d08000dd460aebdca.patch
...
[ <=> ] 941 --.-K/s за 0,001s
2016-01-19 11:05:03 (751 KB/s) - «81e42c7ed0e13e39c95ce02d08000dd460aebdca.patch» сохранён [941]

...

bbw@BwUb:/freerdp-patched$ patch /home/bw/freerdp-patched/freerdp-1.0.2/libfreerdp-core/tcp.c /home/bw/freerdp-patched/freerdp-1.2.0git20151218+dfsg/81e42c7ed0e13e39c95ce02d08000dd460aebdca.patch
patching file /home/bw/freerdp-patched/freerdp-1.0.2/libfreerdp-core/tcp.c
Hunk #1 FAILED at 1027.
1 out of 1 hunk FAILED -- saving rejects to file /home/bw/freerdp-patched/freerdp-1.0.2/libfreerdp-core/tcp.c.rej

@luca-e
luca-e commented Jan 20, 2016

@bw1945 please check if you are really using remmina-next repo. As you can see here: https://launchpad.net/~remmina-ppa-team/+archive/ubuntu/remmina-next freerdp version is 1.2.0~git20151218+dfsg-0

@giox069
Contributor
giox069 commented Jan 20, 2016

@bw1945 I know the problem appeared not so long ago. But I have no idea when and why. I'm still tracking the problem, and now it seems related to openssl BIO_read routine returning an invalid value... (the code is in funciotn transport_read_layer() of libfreerdp/core/transport.c)...
I'm stilli investigating. If anyone could help in digging inside openssl and socket code, recompiling and testing, any help would be appreciated.

@bw1945
bw1945 commented Jan 20, 2016

@luca-e I set repository:
http://ppa.launchpad.net/remmina-ppa-team/remmina-next/ubuntu

@giox069 I believe that the problem occurs near the beginning of November 2015.
Unfortunately, my expertise is not sufficient for effective self-digging :)

Today I worked remotely. Connection valilos not rising automatically many times:

bw@BwUb:$ xfreerdp /v:10 ... /monitors:1 /f +auto-reconnect
[12:49:40:952] [16246:16247] [WARN][com.freerdp.core.nego] - Error: SSL_NOT_ALLOWED_BY_SERVER
[12:49:40:043] [16246:16247] [WARN][com.freerdp.core.nego] - Error: SSL_NOT_ALLOWED_BY_SERVER
[12:50:43:093] [16246:16247] [ERROR][com.freerdp.core] - ERRINFO_DECRYPT_FAILED (0x00001192):(a) Decryption using Standard RDP Security mechanisms (section 5.3.6) failed.
(b) Session key creation using Standard RDP Security mechanisms (section 5.3.5) failed.
[12:50:43:093] [16246:16247] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
[12:50:43:093] [16246:16247] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor
bw@BwUb:
$ xfreerdp /v:10... /monitors:1 /f +auto-reconnect
[12:50:59:280] [16348:16349] [WARN][com.freerdp.core.nego] - Error: SSL_NOT_ALLOWED_BY_SERVER
[12:50:59:369] [16348:16349] [WARN][com.freerdp.core.nego] - Error: SSL_NOT_ALLOWED_BY_SERVER
[12:52:35:576] [16348:16349] [ERROR][com.freerdp.core] - ERRINFO_DECRYPT_FAILED (0x00001192):(a) Decryption using Standard RDP Security mechanisms (section 5.3.6) failed.
(b) Session key creation using Standard RDP Security mechanisms (section 5.3.5) failed.
[12:52:35:576] [16348:16349] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
[12:52:35:576] [16348:16349] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor
...
If I can give you additional useful information, happy to do it, but tell me - how.

@giox069
Contributor
giox069 commented Jan 20, 2016

@bw1945 the error reported by freerdp means that you are trying to connect to a server which does not support SSL. Try to add to the freerdp commandline /sec:nla or /sec:rdp

@bw1945
bw1945 commented Jan 20, 2016

@giox069 Thank you. Apply / sec: rdp.
But I was referring to the fall of error:

bw@BwUb:~$ xfreerdp /v:10... /monitors:1 /f +auto-reconnect /sec:rdp
[14:19:58:109] [18710:18711] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
[14:19:58:109] [18710:18711] [INFO][com.freerdp.client.x11] - Network disconnect!
[14:19:58:109] [18710:18711] [INFO][com.freerdp.client.x11] - Attempting reconnect (1 of 20)
[14:41:22:096] [18710:18711] [ERROR][com.freerdp.core] - ERRINFO_DECRYPT_FAILED (0x00001192):(a) Decryption using Standard RDP Security mechanisms (section 5.3.6) failed.
(b) Session key creation using Standard RDP Security mechanisms (section 5.3.5) failed.
[14:41:22:096] [18710:18711] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
[14:41:22:096] [18710:18711] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor

Here it is received and automatic recovery and without recovery.
Please tell me again: there is a problem with the clipboard and the shared folder - in Remmina was Ok.

@giox069
Contributor
giox069 commented Jan 20, 2016

Clipboard: I can't understand well your question... but I know that xfreerdp has clipboard disabled by default. You must add "+clipboard" to the commandline. But this is off topic in this discussion :)
I'm still doing disconnection testing and I have reached some two other results:

  1. With current libfreerdp socket settings it seems that if only a single TCP keepalive packet get lost, the kernel will detect it as a timeout returning an error on the socket.
  2. This will not happen in older kernels, in which inside the same time window they were able to send other keepalive packet to retry the keepalive operation.
    So it could be a kernel update. If you can, test remmina with an older kernel/distribution (which kernel and distro are you using now ?).
    Tomorrow I will continue testing on the kernel tcp keepalive problems.
@bw1945
bw1945 commented Jan 20, 2016

@giox069 In my opinion it is a good idea.
3.13.0-48-generic
"... If you can, test remmina with an older kernel/distribution..." - I do not know ... How? :(
Himself too long to understand..

And
I'm sorry but thank you :)

@giox069
Contributor
giox069 commented Jan 22, 2016

@bw1945 read my last post on FreeRDP/FreeRDP#3015. And the proposed solution/workaround is still raising TCP_USER_TIMEOUT.
When the freerdp team will merge the pull request, I will update the remmina-next PPA so all ubuntu users will receive the updated freerdp package automatically.
In the meanwhile the autoreconnect feature is under development.

@bw1945
bw1945 commented Jan 22, 2016

@giox069 Ok. Thank you.

@fuziko
fuziko commented Jan 28, 2016

Hello All and especially Geox069!

  1. I will on hard work last week and can't answer, sorry.
    So now i'am back in standart rhytms and can check all you wrote and answer to questions.
  2. "The disconnection problems seems to be inside freerdp. Could someone test
    xfreerdp /v:hostname /u:usermame /d:domainame
    and see if disconnect as frequently as Remmina ?"
    AND NOONE disconnect (visually), with option "+auto-reconnect" bolow logs without this option and with option:
    fuzik@fuzik-desktop:/Загрузки/remote$ xfreerdp /clipboard /v:192.168.30.130 /u:Администратор
    [16:21:31:650] [20769:20770] [INFO][com.freerdp.client.common.cmdline] - loading channel cliprdr
    Password:
    [16:21:35:837] [20769:20770] [ERROR][com.freerdp.locale] - Unable to get current timezone rule
    [16:47:36:560] [20769:20770] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
    [16:47:36:560] [20769:20770] [INFO][com.freerdp.client.x11] - Network disconnect!
    [16:47:36:560] [20769:20770] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor
    WITH ENABLED RECONNECT OPTION:
    fuzik@fuzik-desktop:
    /Загрузки/remote$ xfreerdp /clipboard /v:192.168.30.130 /u:Администратор +auto-reconnect
    [16:49:01:480] [20820:20821] [INFO][com.freerdp.client.common.cmdline] - loading channel cliprdr
    Password:
    [16:49:04:466] [20820:20821] [ERROR][com.freerdp.locale] - Unable to get current timezone rule
    [19:06:00:674] [20820:20821] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
    [19:06:00:674] [20820:20821] [INFO][com.freerdp.client.x11] - Network disconnect!
    [19:06:00:674] [20820:20821] [INFO][com.freerdp.client.x11] - Attempting reconnect (1 of 20)
    [19:06:00:750] [20820:20821] [ERROR][com.freerdp.locale] - Unable to get current timezone rule
    [19:25:53:889] [20820:20821] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
    [19:25:53:889] [20820:20821] [INFO][com.freerdp.client.x11] - Network disconnect!
    [19:25:53:889] [20820:20821] [INFO][com.freerdp.client.x11] - Attempting reconnect (1 of 20)
  3. "@fuziko @bw1945: do you remember if your connection loss was in local LAN or to a remote WAN host ?"
    My connection in LAN-only, throught one gigabit switch in one network.
  4. "So it could be a kernel update. If you can, test remmina with an older kernel/distribution (which kernel and distro are you using now ?)."
    What kernel i must use for test?
    Please refer me to a range of kernels that i can try to test on i

p.s. ohh so stupid autoformatter for the posts rrrhh!

@danboid
danboid commented Feb 24, 2016

giox069:

I can only presume your autoreconnect code hasn't been merged into git yet because I've just built the latest freerdp and remmina git but I still struggle to maintain an RDP connection (to Windows 2012R2) for more than 10 minutes without getting disconnected and I don't see an autoreconnect feature in the remmina RDP options. SSH is fine but RDP connections usually fail within a couple of minutes.

Looks like I'll have to use rdesktop until this is fixed. Are there any plans for remmina to allow using rdesktop instead of freerdp?

@giox069
Contributor
giox069 commented Feb 24, 2016

Autoreconnect branch hasn't been merged due some problems with the ssh tunnel for RDP and another minor bug. I need some time to find the problem and fix it (4-5 days ?).

In the meanwhile, if you are NOT using our ubuntu PPA, you can recompile FreeRDP and get a newer libfreerdp which fixes its own idle timeout problem (patch has been committed yesterday).
See FreeRDP/FreeRDP@be02849

For rdesktop plugins, try to have a look at @muflone website: http://www.muflone.com/remmina-plugin-rdesktop/english/

@danboid
danboid commented Feb 24, 2016

Hi giox

I didn't know about the rdesktop plugin. I've installed that (under Arch) and thankfully it doesn't disconnect like freerdp.

Thanks for the tip!

@giox069 giox069 referenced this issue Feb 28, 2016
Merged

Autoreconnect #776

@giox069 giox069 closed this in e5ce6ac Feb 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment