Ubuntu

rdesktop freezes shortly after successful connection

Reported by dhn on 2008-04-15
62
This bug affects 9 people
Affects Status Importance Assigned to Milestone
rdesktop (Debian)
New
Undecided
Unassigned
rdesktop (Ubuntu)
Undecided
Unassigned

Bug Description

In Gutsy and Hardy, I am able to connect to the server via RDP. Shortly (30sec-1min) after login, the connection freezes---the pointer still responds, but I am unable to see the results of any mouse clicks or keypresses. If I kill the client and reconnect, I see that the mouse clicks and keypresses were being sent to the remote server. There are no side-effects on other X applications---everything continues to work except for rdesktop.

This behavior was identical under Gutsy and on two different Hardy machines, regardless of network interface. I tried the Gutsy rdesktop package and also tried compiling the latest rdesktop cvs, all with the same results. However it worked fine under Dapper.

I normally invoke rdesktop as

rdesktop -a 8 -z -P -U username server

Dropping -z or -P makes the connection quit faster, as does using a higher color depth.

This thread

http://ubuntuforums.org/showthread.php?p=4709775

discusses what appears to be the same problem experienced by other users. Please contact me if further information is needed to diagnose.

Thanks for reporting this bug. Some additional information would be helpful, including the version of rdesktop you are using. "dpkg -l rdesktop" should do the trick in terminal.

Also, you can try the remote desktop session through a different internet connection and make sure that it isn't a problem with the connection (firewall, ect).

dhn (ubuntu-neilson) wrote :

dkpg -l rdesktop shows version 1.5.0-3+cvs20071006. The problem is the same with a current CVS checkout, as well as with version 1.4.1 from www.rdesktop.org.

I have tried connecting from my laptop via several different internet connections, with the same result.

The desktop was running Dapper until a few days ago, and rdesktop worked fine. On the same network connection, rdesktop would fail on the laptop running Gutsy and now Hardy. I switched the desktop to Hardy as well, and now get the same problem there.

process91 (boratko) wrote :

I am experiencing the same problem.

dhn (ubuntu-neilson) wrote :

One additional note: If I wait for the connection to time out, I get

ERROR: recv: Connection reset by peer

in the console.

Daniel Wit Preuss (danpre) wrote :

I have 2 computers:

1. Desktop running 7.10 with:
rdesktop 1.5.0-2
and Cisco VPN client

I can connect from home to my work network and use rdesktop without any problems

2. Notebook running 8.04 with:
rdesktop 1.5.0-3+cvs200
and Cisco VPN client

I can connect from home to my work network and use VNC CLIENT (vncviewer) without any problem
With rdesktop whole computer freezes and I have to turn it off.

On both computers I use:
rdesktop -f -k pl -a 8 -z -u user_name -d domain_name -p password 192.168.95.94

But:
this notebook and the same command started directly in my work network (without Cisco VPN client) works without any problems! (I use many connections for many hours a day)

dhn (launchpad-neilson) wrote :

Daniel, I believe your problem is different, though they may be related. This bug is about a crash that takes down only rdesktop, not the whole system, and that does not involve the Cisco VPN client, which is not involved in my setup.

process91, can you confirm that you are not using Cisco VPN?

Daniel Wit Preuss (danpre) wrote :
process91 (boratko) wrote :

I can confirm that I am not using Cisco VPN, and the crash is limited to only rdesktop. I also get the "ERROR: recv: Connection reset by peer" if I wait for the connection to time out. Attached is a screenshot, while don't think it will be helpful in identifying the problem maybe some other people have this issue and would possibly better recognize an image of the situation than a description.

mrcomanche (mrcomanche) wrote :

HI all,

I am having the same problem as DHN.
vpnc 0.5.1r275-1 Cisco-compatible VPN client
rdesktop 1.5.0-3+cvs20071006 RDP client for Windows NT/2000 Terminal Server
Linux ubuntu 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

I also use a Telecom 3G (NZ) connection with a pretty good signal strenght.
IMPORTANT:
I realized that my VPN connection disappears during the problem. I would say maybe the VPN connection closes first, and that's why the rdesktop freezes, but DHN says every mouse action actually has effect, we just cannot see it. In this case rdesktop must crash first.

Cheers

process91 (boratko) wrote :

@mrcomanche
If you are having a problem in relation to the Cisco VPN client then I would suggest you add your comments to https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/218308. DHN and I have been having a problem with rdesktop completely unrelated to the VPN client.

dhn (launchpad-neilson) wrote :

This bug is still present in rdesktop 1.6.0 (under Hardy).

process91 (boratko) wrote :

Can confirm that this bug is still present in rdesktop 1.6.0 under Hardy.

process91 (boratko) wrote :

This is becoming increasingly frustrating to deal with... it means I can't use ubuntu if I can't connect to a windows machine remotely using remote desktop. It's gotten to the point where I have tested absolutely everything and the only variable consistently causing the problem is Linux. I have a Windows XP computer which connects to the remote desktop fine at full speed (almost realtime) and resolution. I tried the same exact network cable and on linux the remote desktop session is very very slow and it freezes.

I also installed windows in VirtualBox, and the remote desktop connection is just as bad as using rdesktop in Linux! This seems very strange to me. Is Ubuntu shaping the traffic? Everything is much too slow to be useful. I installed windows on the same machine and dual-booted and the remote desktop connection was perfect.

Daniel Wit Preuss (danpre) wrote :

I can confirm again that using rdesktop 1.5.0-3+csv200710 I have NO PROBLEMS.

I'm connecting from Hardy to windows machines:
windows 2000 advanced server
windows 2003 server (regular server)
windows 2003 server (vmware machine)
windows xp professional (regular desktop)
windows xp professional (vmware machine)

NO PROBLEMS

The same when I'm connecting to my company network from home using vpnc 0.5.1r275-1.

NO PROBLEMS

It works even better than original windows xp remote desktop client (original windows xp have problems with national signs)

process91 (boratko) wrote :

This is still huge problem. Maybe I'm not running something correctly, on either side. I have installed Ubuntu Hardy on over 6 machines with the same effect. I've attached a screenshot of what I get. I'm running the following command:

rdesktop server.example.com:9807

I then get a window which displays as shown in the screenshot, and it completely stops. If I let it run for about 3 minutes I will get a response of "Connection reset by peer". I did get one laptop to work correctly, and it was not due to any additional configuration or modification, it worked directly after installing a standard Ubuntu installation however it was very very slow, to the point where it was not usable.

Here's the message I get back from rdesktop when running the above command:

Autoselected keyboard map en-us
WARNING: Remote desktop does not support colour depth 24; falling back to 16
ERROR: recv: Connection reset by peer

The connection works flawlessly on a Windows XP machine on the same network. I have also installed Windows XP on one of the computers that was not working with Ubuntu and it worked correctly as well. I have the same thing happen in a Virtual machine running Windows XP. I'm beginning to think this is something more deeply rooted than just rdesktop, since even running Windows XP in a virtual machine gives me the same results.

dhn (ubuntu-neilson) wrote :

This appears to be fixed as of rdesktop package version 1.5.0-3+cvs20071006ubuntu0.1. I have been connected for 10+ minutes for the first time in months. Can anyone confirm?

dhn (ubuntu-neilson) wrote :

Amending my previous comment: on my laptop, this update fixed the problem. On my desktop, there has been no change.

This did not fix the problem for me at all. Running with 8 but color
seems to speed things up a bit (-a 8) but it is still not really
usable or nearly as close to the speed of a windows XP machine on the
same connection.

On 9/19/08, dhn <email address hidden> wrote:
> Amending my previous comment: on my laptop, this update fixed the
> problem. On my desktop, there has been no change.
>
> --
> rdesktop freezes shortly after successful connection
> https://bugs.launchpad.net/bugs/217868
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sent from Gmail for mobile | mobile.google.com

Michael Boratko
Cell (860) 538-5736
<email address hidden>
www.starstreak.com

stopdatrue (xebrun) wrote :

Same problem for me, access winxp pro rdesktop cause system freeze after few seconds.

(intredpid: rdesktop 1.6.0-2ubuntu1)

porlo (kenkenchu) wrote :

I've got the same problem and have tried various combination of configs and versions of cisco vpn and rdesktop. Finally I believe I've found a workaroud. If I run vpnclient as a normal user, the issue occurs. But if I run it as root like 'sudo vpnclient connect <profile>' the rdesktop issue doesn't happen again.

I'm running 64-bit hardy with rdesktop 1.6.0, cisco vpn x86_64-4.8.01 with patches.

porlo (kenkenchu) wrote :

No, the issue comes back today even when i was running vpn client as root...

Fülöp Róbert (fulopr) wrote :

The same situation at me. My only workaround is that I switch off the movement actions on the last tab, then it work well, but it's a little bit uncomfortable. It will be great that we can get a real solution.

I believe that there is a genuine problem with rdesktop, but also with gnome.
I use CISCO vpn, that might be the cause of rdesktop crashing, however rdesktop not only crashes but locks the mouse and keyboard inputs, even when the focus is not on the rdesktop window. The system becomes completely frozen and the only "local solution" is to manually reset.

FYI, this is being looked at the following bug report:
https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/81854

Mircea Deaconu (mirceade) wrote :

Same problem on Intrepid rdesktop 1.6.0-2ubuntu1.

Bassu Khan (bashukhan) wrote :

I can confirm that this is the issue with rdesktop (all versions usually) in Ubuntu.
My details:

Rdesktop version 1.5.0.
1.5.0-3+cvs200

The session freezes, though its not disconnected from host's side but I have to simply close or kill the rdesktop session from here as soon as it freezes.
And when i try to connect again it creates a new session; just because the other session which I had to kill, is usually seen as active on the host machine. There is no way to configure auto-reconnect or to connect to the same last session besides creating a new one. So, this is really a horrible experience at the time. Please fix it if you are working on it. Thanks.

Bassu Khan (bashukhan) wrote :

Two more things I noticed:

- rdesktop timesout if kept idle for 15-20 minutes
- sometimes when rdesktop freezes the a few of the windows are not close-able
- sometimes a few windows show blank screen as well

This behavior is quite odd. I downloaded a couple of more old and newer versions, compiled but still couldn't get a stable RDP connection. This seems to be problem with Ubuntu core..!

Bassu Khan (bashukhan) wrote :

One more symptom I've found. Often keyboard becomes unresponsive. Probably the one similar in https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/81854

I've seen a lot of bug reports about rdesktop in Ubuntu. Why don't Ubuntu devs fix rdesktop out?

This really drives people crazy, particularly the ones who on daily basis have to interact with remote desktop!

Spend three ours finding and fixing, but couldn't. This is not the issue with rdesktop, its an Ubuntu problem.

GaryC (g-cunningham) wrote :

hmmm 3 years later and still not fixed......

http://osdir.com/ml/network.rdesktop.devel/2006-10/msg00044.html

If i do above...lockup occurs every time.

im having random lockups, on 8.04/8.10 and 9.04 alpha 3

I have determined vpn tunnel is still active and ok, the gnome menu bars dont work although mouseover events still work. Keyboard is locked up too. Have spent last two months trying everything to resolve this. Am really frustrated now, and bought two laptops for remote workers which I cant get working and my boss is getting pretty annoyed at me at not getting this working.

is rdesktop still being developed ne1 know ???????? or are there any viable alternatives.

I have read posts with same prob in fedora (above link) and suse, so it does point to an rdesktop issue ????

Dawning (dawning) wrote :

I personally prefer RDP, but maybe you can get by on VNC for now, it seems to be fairly actively pursued to me.

dhn (ubuntu-neilson) wrote :

GaryC, this bug is for a different issue. In this bug, the whole system does not lock up, just the rdesktop client. The client can be killed without restarting the system.

Also this is for a connection without VPN. Bug

https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/218308

describes an rdesktop problem involving VPN.

Rdesktop 1.6.0 was released in May 2008. As far as I know development is ongoing. There are no other RDP clients for linux.

Dawning (dawning) wrote :

Okay, so I personally hate this suggestion I'm about to make.. But any idea if mstsc.exe (the MS rdp client) runs in Wine? I'll reiterate, I don't consider that remotely close to a solution of any real kind.

Maybe rdesktop could just use some people declaring how much they'd prefer to use it and appreciate that others are able/available to develop it further?

dhn (ubuntu-neilson) wrote :

I actually tried this at some point, to no avail. I forget exactly how it failed.

I also tried running MSTSC on WinXP and Win2K virtual machines under VirtualBox. Interestingly, I had the same problem that I have with rdesktop. This led me to suspect a problem with something in Ubuntu rather than with rdesktop itself, however I don't know enough about all of the dependencies to say where to look or whether this makes sense.

All of these problems occur on my desktop. rdesktop runs fine on my laptop, which also runs Hardy.

It's a persistent and frustrating problem, to say the least.

Bassu Khan (bashukhan) wrote :

Exactly! The same issue I noticed too. I spent hours investigating that. This is an issue with the Ubuntu and few other Linux distributions' core. Not an average normal user would find that but if you're an advanced user and you use rdesktop regularly you'll see a lot of ill behaviours of rdesktop in all Linux distros.
For me Linux is just a server OS far away from the needs of today's power desktop users and Ubuntu needs to learn more discipline in better desktop computing cause of the proclaims it made. Its not just the rdesktop but other tools as well which wastes hundreds of hours of thousands of users each day battling around their ways and finding the fixes for such 'lost' bugs like this one! :P
This is why I switched back to Windows. I do use Ubuntu but only as a server operating system and appreciate its stability for a few servers rolling tools its currently running in, just because have don't much time to do more to fix such sort of issues unfortunately which I was facing every minute when I had it.

Fran Taylor (narf-muppetlabs) wrote :

Hey Bassu Khan, the bug turns out to be a Windows networking issue:

http://blog.tmcnet.com/blog/tom-keating/microsoft/remote-desktop-slow-problem-solved.asp

I was having this problem big-time, and the advice in this article totally fixed the problem for me.

Perhaps in the future you should withhold your opinions until the facts are in.

Bassu Khan (bashukhan) wrote :

Hi Fran Taylor,

Thanks for the info but I can see this is not the case here! I already have audited all of the networks for any such packet issues. The problem dramatically appears when I rdc into ALL of the Windows machines in all networks. I RDC into four different data centers from my three different internal networks and the rdesktop 'timeouts' only occur when using 'rdesktop' from Linux. How come this is happening only in 'rdesktop' in all 6 totally different networks on all machines so this is definitely not the case ;)

One of the major issue which cracks me up, is the timeout as slowness is acceptable as far as I'm able to work on remote machines! Rdesktop locks up, freezes, crashes or simply timeouts when left inactive or minimized for some time and I duplicated this a lot more on Hardy and Interpid.

Fran Taylor (narf-muppetlabs) wrote :

Bassu,

Perhaps you are seeing a different bug. The original bug as described, and the one I encountered, are manifested shortly after login, NOT after a period of inactivity, as you describe.

Kevin (kevin-matson) wrote :

I've been experiencing the same problem connecting to my Windows servers with RDP on Ubuntu. I don't know if Ubuntu does bounties on bugs but I'd be willing to pay for some developer time to get this fixed.

Kevin (kevin-matson) wrote :

I take a bit of my previous comment back. If I use Kvpnc as my VPN front end I don't run into the lockup problems. I'm disappointed that network manager VPN front end doesn't seem to be setting this up correctly. Now I'll put money behind getting the network manager VPN front end fixed so I don't have to kludge around it like this.

I have a similar problem (but haven't always had it). I run a fully up to date 8.10 and when connecting using rdesktop (version 1.6.0) the following scenarios can happen:

1. rdesktop connects, but soon after (sometime you can perform some work, sometimes not), it locks and doesn't refresh the screen.

2. rdesktop connects, but soon after it locks as with 1, and Ubuntu's desktop doesn't accept keyboard input, some windows can't be dragged. If I go to another Workspace, I can open a terminal and have keyboard input (so I can type "killall rdesktop" which solves the problem.

Please note that in Windows XP the connection is also very slow (I dual boot). Our internet here is not very fast nor reliable, but it also happens when connecting to hosts on our local wireless network.

dhn (launchpad-neilson) wrote :

This bug (as originally reported by myself and process91 in the first couple of posts, i.e. with no VPN involved) is fixed for me after upgrading from Hardy to Jaunty. rdesktop version is unchanged. process91, can you confirm? Anyone else?

Still hangs for me, although previous testing has indicated that some remote
desktop connections work flawlessly, while others do not without any obvious
explanation.

Michael Boratko
Cell (860) 538-5736
<email address hidden>
www.starstreak.com

On Tue, May 19, 2009 at 3:53 PM, dhn <email address hidden> wrote:

> This bug (as originally reported by myself and process91 in the first
> couple of posts, i.e. with no VPN involved) is fixed for me after
> upgrading from Hardy to Jaunty. rdesktop version is unchanged.
> process91, can you confirm? Anyone else?
>
> --
> rdesktop freezes shortly after successful connection
> https://bugs.launchpad.net/bugs/217868
> You received this bug notification because you are a direct subscriber
> of the bug.
>

joebodo (joebodo) wrote :

After roughly 20-30 minutes, rdesktop freezes and the window is not closeable (taskbar or top close button)

I have to kill the pid in a terminal in order to close the window. The server still shows that the connection is established - meaning, I have to open a another session on the server and disconnect my killed session using terminal services manager.

I have been using this connection without issue in Windows for close to a year.

Specs:
Jaunty: 2.6.28-13-generic
rdesktop: 1.6.0-2ubuntu1
No VPN

Bassu Khan (bashukhan) wrote :

joebodo, I've been seeing this problem for almost two years the time since when I switched to Debian/Ubuntu.
This occurs when you'll keep your rdesktop windows minimized for about 20-30 mins. This is something I feel that Gnome/Rdesktop does and not the client machines you're connecting to. I've tried a lot to find a reason for this rdesktop behaviour but couldn't even though at one I suspected Compiz causing that!

And a more interesting thing is that, this sometimes happens with other Linux distros as well.
Again, if you'll keep your window maximized or just active under the current top window of any application, you'll likely not encounter the issue.

joebodo (joebodo) wrote :

Thanks for that info - one less frustration to contend with...

On Wed, Jul 1, 2009 at 4:50 AM, Bassu Khan <email address hidden> wrote:

> joebodo, I've been seeing this problem for almost two years the time since
> when I switched to Debian/Ubuntu.
> This occurs when you'll keep your rdesktop windows minimized for about
> 20-30 mins. This is something I feel that Gnome/Rdesktop does and not the
> client machines you're connecting to. I've tried a lot to find a reason for
> this rdesktop behaviour but couldn't even though at one I suspected Compiz
> causing that!
>
> And a more interesting thing is that, this sometimes happens with other
> Linux distros as well.
> Again, if you'll keep your window maximized or just active under the
> current top window of any application, you'll likely not encounter the
> issue.
>
> --
> rdesktop freezes shortly after successful connection
> https://bugs.launchpad.net/bugs/217868
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “rdesktop” package in Ubuntu: Incomplete
> Status in “rdesktop” package in Debian: New
>
> Bug description:
> In Gutsy and Hardy, I am able to connect to the server via RDP. Shortly
> (30sec-1min) after login, the connection freezes---the pointer still
> responds, but I am unable to see the results of any mouse clicks or
> keypresses. If I kill the client and reconnect, I see that the mouse clicks
> and keypresses were being sent to the remote server. There are no
> side-effects on other X applications---everything continues to work except
> for rdesktop.
>
> This behavior was identical under Gutsy and on two different Hardy
> machines, regardless of network interface. I tried the Gutsy rdesktop
> package and also tried compiling the latest rdesktop cvs, all with the same
> results. However it worked fine under Dapper.
>
> I normally invoke rdesktop as
>
> rdesktop -a 8 -z -P -U username server
>
> Dropping -z or -P makes the connection quit faster, as does using a higher
> color depth.
>
> This thread
>
> http://ubuntuforums.org/showthread.php?p=4709775
>
> discusses what appears to be the same problem experienced by other users.
> Please contact me if further information is needed to diagnose.
>

@Daniel Wit Preuss (danpre):
> On both computers I use:
> rdesktop -f -k pl -a 8 -z -u user_name -d domain_name -p password 192.168.95.94

The -f switch makes rdesktop for full-screen. When your computer "freezes" it's actually only rdesktop. You can kill it from another session by, for example, pressing Ctl+Alt+F5 and logging in then running "pkill rdesktop" and pressing Ctl+Alt+F7 to get back to your Gnome desktop.

This is still a problem (or has come back) in rdesktop 1.6.0 on Maverick.

I've been using rdesktop this week to work from home. Despite the freezes (perhaps a half-dozen times just today) it still seems to be the best RDP client I've tried on Ubuntu - doesn't limit you to 1400x1050 resolution (tsclient), the right-hand Shift and Ctl keys work (Remmina) and Ctl+Alt+A works remotely for KeePass (krdc).

I do not use a VPN although I am punching through a firewall at the remote end, ala:

rdesktop -u USERNAME -p PASSWORD -k en-us -g 1910x1130 -b -N -z -xb -r sound:local -r clipboard:PRIMARYCLIPBOARD -0 -5 SERVER.FQDN:15002

I have a 1920x1200 desktop locally, so I use the -g switch to get a local window slightly smaller than my desktop so I can still click on the local task bar to switch apps, etc. Sometimes when rdesktop freezes clicking on its Close window decoration won't even close it, but I can just switch to System Monitor to End Process it. I have not yet had it lockup the whole system.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers