X11 client freezes indefinitely if connection is lost about freerdp

[otavio]

This is clearly a regression so I tagged it according.

[eduardobeloni]

I reckon xfreerdp gets stuck in the select, which handles fds from tcp, window events, among others. This way, it can't detect a connection failure.

xfreerdp.c's select:

freerdp_get_fds(instance, rfds, &rcount, wfds, &wcount)
...
freerdp_channels_get_fds(channels, instance, rfds, &rcount, wfds, &wcount)
...
xf_get_fds(instance, rfds, &rcount, wfds, &wcount)
...
if (select(max_fds + 1, &rfds_set, &wfds_set, NULL, NULL) == -1)

[otavio]

I think this select ought to enforce a timeout to allow you to handle the non-connection case. This way you might be able to check the specific fds to know if it is really working or not. IIRC the RDP has a keep-alive type of package and thus this ought to allow us to proper detect this case.

[awakecoding]

@otavio I added some code today to have select() timeout after some time, which lets us do something. But then I couldn't figure out a way to get proper disconnection detection. We'll need to keep looking into it I guess.

[otavio]

Easy to test, if you are connecting to a remote VM you can just unplug the network cable (phsically or virtual) from it and see how the system behaves.

[rbhkamal]

Any updated on this? Right now the latest git gives a black window and sits there forever. When I bring the server back online, the RDP window exits.

[bmiklautz]

@rbhkamal thanks for the update - there isn't a fix for now ;( but I hope we can fix this for 1.1

[rbhkamal]

I'm trying to hack in a fix and it seems like there are two places where XFreeRDP gets stuck. The first place is in libfreerdp/utils/tcp.c: freerdp_tcp_wait_write. There is a select statement there that hangs the entire program IF the user generates mouse clicks while the server is down. I fixed that by putting a 10 second timeout and made freerdp_tcp_wait_write return -1.
The second part is in the client code (same place as 2 years ago) xf_interface.c: xf_thread.
select(max_fds + 1, &rfds_set, NULL, NULL, &timeout)

I don't quite understand what the rfds_set is, is it only for X11 events?
The problem I believe can be solved by simply creating a function that checks the status of the transport sockets and use it when the select above times out.
Something like this:
state = select(socketfds+1, &fds, , NULL, &timeout)
if (state == 0)
// See if reading/writing from socket produces an error (any error)
state = recv(sockfs, data, length, 0);
if ( state <= 0)
abort or increment a counter or start a timer to close everything.

I'm not an expert in RDP protocol but is there such thing like heartbeats for RDP?
http://stackoverflow.com/questions/5640144/c-how-to-use-select-to-see-if-a-socket-has-closed
bool isclosed(int sock) {
fd_set rfd;
FD_ZERO(&rfd);
FD_SET(sock, &rfd);
timeval tv = { 0 };
select(sock+1, &rfd, 0, 0, &tv);
if (!FD_ISSET(sock, &rfd))
return false;
int n = 0;
ioctl(sock, FIONREAD, &n);
return n == 0;
}

[rbhkamal]

Setting keepalive on the socket fixes everything, not sure of this is a real solution but at least it is a workaround.

[Goddard]

still effecting latest for me kubuntu 14.04

[bmiklautz]

When activating keep alive (as @rbhkamal mentioned) it works in most cases but not if there is still outgoing data pending in the TCP socket.
I believe this issue should be finally fixed once #2409 is merged. (When all keep alive settings and TCP_USER_TIMEOUT is available and compiled in)

[bmiklautz]

Closing this issue due to inactivity. If the problem still exists with the current master branch please re-open or create a new one.

[Enverex]

This is still an issue but not universally. Just had about 50 machines lose connection to the host. After ~5-10 minutes some machines closed off the client (which is still a surprisingly long time), others just stayed frozen indefinitely. Even worse is that xFreeRDP wouldn't release the keyboard so users couldn't actually type outside of xFreeRDP anymore either (or kill it off with keyboard commands).

[bmiklautz]

@Enverex seems quite long true but there shouldn't be any indefinite freezes anymore (as the issues says).
For completeness what version did you experience the this behavior with?

[Enverex]

1.2.0-beta1 apparently. I can't update further because that brings in a new set of bugs regarding how multi-monitors are handled (or rather, how they aren't - specifically #2863 (comment)).