Rdesktop cousing system freeze when using Cisco VPN client

Bug #218308 reported by Daniel Wit Preuss
30
This bug affects 2 people
Affects Status Importance Assigned to Milestone
rdesktop (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: rdesktop

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)

Revision history for this message
Adam Bartoszewicz (adamb-info-s) wrote :

I confirm this bug. I use:
- Ubuntu 8.04
- vpnclient-linux-x86_64-4.8.01.0640-k9 with patch vpnclient-linux-2.6.24-final.diff
- rdesktop -a 16 -f -u username -p password some_ip_address
My computer completly freezes after 1 - 5 minutes.
I found also this link http://ubuntuforums.org/showthread.php?t=748479

Revision history for this message
Antoni Abella Vendrell (antoni-abella) wrote :

I have very similar settings and I have the same problem, even with the sound disabled.
I believe that the guys in the bug report below are getting close to the source of the problem:
https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/81854

Revision history for this message
Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 9.04?

Changed in rdesktop:
status: New → Incomplete
Revision history for this message
Simon Vidmar (vidmar-simon) wrote :

I have similar problem, but mostly this happens usually when I am connected to wireless network. When using cable connection to network it is usually OK.

Revision history for this message
Mike McCune (mjmccune-gmail) wrote :

I have a similar problem on 8.04. It doesn't lock up but rdesktop freezes and the VPN connection drops.

Changed in rdesktop:
status: Incomplete → Confirmed
Revision history for this message
GaryC (g-cunningham) wrote :

Hmmmm where do I start

Tested all this in 2 dell laptops and one lenovo, tested using ubuntu 8.04/8.10/9.04 alpha 4.

symptoms: rdesktop session stops responding to key/mouse input eventually crashing gnome.Hmmmm where do I start

Tested all this in 2 dell laptops and one lenovo, tested using ubuntu 8.04/8.10/9.04 alpha 4.

Common factors : All use gnome desktop/rdesktop 1.6.0/all have intel iwl3945 (but did buy an atheros card and tried it as well). All rdesktop connections are over pptp vpn connection. all connect via command prompt

What goes wrong: rdesktop randomly freezes (anything from 1 second to max of about 20min), no input via keyboard or mouse has any effect on the rdp session.

What I have tested: Ubuntu 8.04/8.10/9.04A4 / Fedora 10 and Opensuse 11.1 all exhibit same problem.

Observations:

a wired pc running Ubuntu 7.04 runs 100% (running rdp 1.5.0)

a wired xp pro sp2 desktop PC works 100% fine

when rdesktop freezes if i am dont close it quickly it brings the whole of gnome down in a hardlock

the vpn tunnel is still fully operational during rdesktop freeze (I can ping PCs on remote lan/admin remote router and if i immediatley restart rdesktop it connects and works fine for 1sec to 20min as normal)

I came up with the bright idea (or desperate) of using XP Pro in a virtualised environment with ubuntu providing the vpn tunnel, guess what IDENTICAL behaviour, ie after random time xp remote desktop stops responding in the same manner. Eventually comes up with error "the connection was ended because of a network error".

Common factors : All use gnome desktop/rdesktop 1.6.0/all have intel iwl3945 (but did buy an atheros card and tried it as well). All rdesktop connections are over pptp vpn connection. all connect via command prompt

What goes wrong: rdesktop randomly freezes (anything from 1 second to max of about 20min), no input via keyboard or mouse has any effect on the rdp session.

What I have tested: Ubuntu 8.04/8.10/9.04A4 / Fedora 10 and Opensuse 11.1 all exhibit same problem.

Observations:

a wired pc running Ubuntu 7.04 runs 100% (running rdp 1.5.0)

a wired xp pro sp2 desktop PC works 100% fine

when rdesktop freezes if i am dont close it quickly it brings the whole of gnome down in a hardlock

the vpn tunnel is still fully operational during rdesktop freeze (I can ping PCs on remote lan/admin remote router and if i immediately restart rdesktop it connects and works fine for 1sec to 20min as normal)

I came up with the bright idea (or desperate) of using XP Pro in a virtualised environment with *ubuntu providing the vpn tunnel*, guess what IDENTICAL behaviour, ie after random time xp remote desktop stops responding in the same manner. Eventually comes up with error "the connection was ended because of a network error".

If i try to setup/connect vpn tunnel in virt xp, it timesout with error 721 remote computer did not respond.

not sure, but i think this is a flaw in linux networking but posted it here for others apraisal

i have been troubleshooting this for over 2 months now and am sooooooooooooo frustrated :(

Revision history for this message
GaryC (g-cunningham) wrote :

***SORRY can admin delete my prev post as my copy/paste went wrong...thanks

Hmmmm where do I start

Tested all this in 2 dell laptops and one lenovo, tested using ubuntu 8.04/8.10/9.04 alpha 4.

Common factors : All use gnome desktop/rdesktop 1.6.0/all have intel iwl3945 (but did buy an atheros card and tried it as well). All rdesktop connections are over pptp vpn connection. all connect via command prompt

What goes wrong: rdesktop randomly freezes (anything from 1 second to max of about 20min), no input via keyboard or mouse has any effect on the rdp session.

What I have tested: Ubuntu 8.04/8.10/9.04A4 / Fedora 10 and Opensuse 11.1 all exhibit same problem.

Observations:

a wired pc running Ubuntu 7.04 runs 100% (running rdp 1.5.0)

a wired xp pro sp2 desktop PC works 100% fine

when rdesktop freezes if i am dont close it quickly it brings the whole of gnome down in a hardlock

the vpn tunnel is still fully operational during rdesktop freeze (I can ping PCs on remote lan/admin remote router and if i immediately restart rdesktop it connects and works fine for 1sec to 20min as normal)

I came up with the bright idea (or desperate) of using XP Pro in a virtualised environment with *ubuntu providing the vpn tunnel*, guess what IDENTICAL behaviour, ie after random time xp remote desktop stops responding in the same manner. Eventually comes up with error "the connection was ended because of a network error".

If i try to setup/connect vpn tunnel in virt xp, it timesout with error 721 remote computer did not respond.

not sure, but i think this is a flaw in linux networking but posted it here for others apraisal

i have been troubleshooting this for over 2 months now and am sooooooooooooo frustrated :(

Revision history for this message
GaryC (g-cunningham) wrote :

just some more info if it helps

tonight i connected to my remote office via a vpn tunnel using nm-pptp over wireless from my lenovo n200 laptop.

I initiated two simultaneous remote desktop sessions, one from ubuntu terminal and one from xp pro running inside of virtual box.

both "crashes/froze" at roughly the same time. however the xp machine continued to refresh the screen, but would not accept any keyboard or mouse interactions. The rdesktop 1.6.0 running on Ubuntu (9.04 Alpha 5 - also as mentioned earlier I have same prob on 7.10/8.04 and 8.10).

Also during the freeze the keyboard and mouse had no interaction with the gnome desktop or menus. I was unable to close the rdesktop session as the mouse had no effect, BUT i was able to close the terminal window that i used to launch rdesktop, and immediately all mouse and keyboard functions were restored.

An interesting ? thing I noticed is that when I go back to the virtualbox XP Pro and do a tracert to my target PC on the remote LAN, it hits my ISP then bombs out the virtualbox (whole package crashes/closes without warning), but if I do this before rdesktop "freezes" then it traces the route to my target pc on the remote lan 100% fine.

Also of note during the "freeze" on the virtualbox pc when I click or initiate mouse movements then the "network activity" flashes correspondingly, so it seems that mouse/keyboard is being transmitted over the network.

It is just my hunch that this is either a bug in rdesktop which grabs all keyboard/mouse activity and/or a traffic routing problem over the vpn (does rdesktop do any route modification does anyone know??). When I use rdesktop over my home lan via wireless (no vpn) it works 100% reliably.

PS If sound is enabled it freezes immediately on the xp rdp.

Revision history for this message
GaryC (g-cunningham) wrote :

Hi, another update, and fingers crossed I seem to have solved the problem.

On the remote computer(s) we are connecting to over the vpn, we assigned a static ip address, and used open dns server 208.67.220.220 & 208.67.222.222 as pri & sec dns servers. As per previous post and suspecting a network issue, we changed the dns servers on the remote PC to the ip of the local router, and the sec dns server as one of our ISP's dns servers. Since I have done this is has remained 100% operational for 5+ hours per session over several days. I have been reading on the internet about opendns incorrectly routing data, and can anyone else confirm if they were/are using opendns ?? thanks

Revision history for this message
crispy (peter-murdoch770) wrote :

I was experiencing the rdesktop freeze using vpnc latest stable (.5.1r334-1) on Debian Lenny and ultimately resolved the issue by installing vpnc .3.3+SVN20051028-3.

I had tried stay alive pings, switching from amd64 to i386, but the freeze still occurred. I also tried turning sound off (neither remote or local) in rdesktop per a thread suggestion there, but the freeze seemed to persist. The destination network uses DHCP to allocate IPs.

Revision history for this message
Carl Davis (carl.davis) wrote :

I can confirm that this happen son 9.04. I do think I might have identified an AP/router that doesn't seem to lock up. I also reproduced the problem while using virtualbox.

Revision history for this message
Leon (leont58) wrote :

Cisco VPN client + Wireless + Multiple CPUs (SMP) = CPU freeze.

There is a problem with Cisco VPN client when used on a wireless network with multiple CPUs. I was able to verify this by connecting my laptop to a wired ethernet line without any problems. When I went wireless, my laptop froze.

I'm not sure what you can do in Windows, but in linux, I disabled one of my processors prior to establishing my VPN connection and everything works fine. (ex. # echo 0 > /sys/devices/system/cpu/cpu1/online )

After I disconnect, I re-enable the CPU. ( ex. # echo 1 > /sys/devices/system/cpu/cpu1/online )

Revision history for this message
olikaf (olivier-fresse) wrote :

I have this issue in ubuntu 9.014, 64 bits.

Linux xxxx 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux

I use a pptp vpn through wifi.

Ping & HTTP access via the vpn works fine.
As soon as rdesktop starts, the system freeze
Killing the rdesktop process via a terminal console brings it back to life.

Revision history for this message
abatcher (geens-toon) wrote :

I ran into this bug today too, exactly as #13. I tried with and without wifi. I tried with 9.10 and and older 8.04.
It's usuable for a few seconds and then locks the system up. The only way to save the system is ssh'ing in from another machine and killing tsclient/rdesktop.

Then I might have found the problem/workaround:
In the performance tab in tsclient, check the "Hide window manager's decorations" option.

It's running on both 9.10 and 8.04 for about 10 minutes and looks stable.

Revision history for this message
Chris (clukas-luhala) wrote :

I've confirmed abatcher's comment above. checking "Hide window manager's decorations" appears to fix the problem.

Revision history for this message
Chris (clukas-luhala) wrote :

Taking back my confirmation above. This problem seems to occur based on particular connections. In some areas of my office campus, the problem is non-existent. In others, it is consistently reproducible. Based on this, it might have to do with connection speed, quality or some router / wifi card combination.

Revision history for this message
abatcher (geens-toon) wrote :

Chris, maybe the network admins are using transparent vpn routing to interconnect some remote parts of the campus together ?

I've set up a transparent vpn with pppoe to connect a remote office with ours. Using rdesktop over this (transparant) vpn makes it crash too. How does the application notice its going over a transparent vpn is a big ?

I will try vpn over ssh later and report back. I don't really know it would make any difference ..

Hiding the window manager's decoration works around the problem, but I'd really like to know how this can happen ?

Revision history for this message
crispy (peter-murdoch770) wrote :

Apparently there's a conf option which can be set that prevents the lockup from occurring. If you're using the network-manager vpnc client, it appears as 'Disable dead peer detection.' With this option, on both Debian Squeeze and Ubuntu 11.04, I no longer receive the lockup on the same network where I used to receive the lockup (which has not changed in hardware or vpn configuration). I can look up the .conf setting if anyone needs help googling for it

Revision history for this message
mobrien118 (mobrien118) wrote :

Crispy:

Are you saying that with this option ENABLED you are no longer having issues?

I ask because I have had it enabled and disabled alike and, although the lockups may be less frequent, they are still occurring for me, even with it on.

Thanks for posting. I was very hopeful for a second that we had a solution...

It seems, from this thread, that there are lots of things that work for *some* people, consistently, but nothing that works for me yet. I'm sure that the solution is something involving the "least common denominator" of all of these. Something network related.

I'm definitely not a network guru, so I don't have a lot to offer toward a solution, but if I see a possible solution posted here, I'm bound to try it.

Cheers,

--mobrien118

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.