Rdesktop started life off as a reverse engineering project by Matt Chapman, and has grown into a mature, well-implemented application that fulfills the same function as the terminal services client for Windows, with one major advantage: it runs on almost every Unix-like operating system available. It has been available now for many years in ever more feature-rich versions; the latest iteration, version 1.3.0, now supports Microsoft's RDP 5 protocol. This allows rdesktop to display your Windows desktop in full 24-bit colour, copy and paste text back and forth from the terminal server, play sounds from the server on your local PC, and much more.
Rdesktop fills a unique position in the world of integration products available for mixed Windows and *nix computing environments; while offering functionality similar to VMware, Win4Lin, or even Wine, it has the major advantage of allowing a GNU/Linux user to connect to an actual, real Windows machine, just as if they were working locally on it. Some things just can't work as well in a virtualised environment as a real one.
Rdesktop supports both the Microsoft RDP protocol versions 4 and 5. RDP is a protocol for describing and interacting with all the elements that make up a Windows desktop (Start button and all) over the network. In this way it is almost analogous to the ability to run X11 applications over the network.
I have been using rdesktop now for quite some time to connect to a wide array of Windows servers: NT4 Terminal Server Edition, Windows 2000 in both Administrative Terminal Services and Application Server modes, Windows 2003 in both Administrative Terminal Services and Application Server modes, and Windows XP Pro with Remote Desktop Assitance enabled. Even more impressively, this access has been from both GNU/Linux computers and Sun Solaris SunRay thin client terminals.
Rdesktop version 1.3.0 is rock steady; if you connect to a server, barring an act of God, you stay connected. Previous versions occasionally had difficulty staying connected when Windows did unusual things. I have run rdesktop in 24-bit colour over a 56K dialup without it missing a beat. You can't play sounds over this sort of link, but the stability of the connection cannot be faulted. RDP 5 allows for faster transmission of screen information, so when using it to connect to an RDP 5-capable server (e.g. Windows 2003) in 8-bit colour mode over a dialup line, things are very fast indeed. In fact, it is much faster than using an X11 application over the same link (that includes using LBX proxying, but not extensions like NoMachine).
The bad news is that if you do have difficulty connecting to the server, troubleshooting is more difficult than for rdesktop's Windows analogue. Rdesktop doesn't have any way of conveying the Windows error messages that a server would usually return to the user. The best that you will generally get out of it is a generic 'Connection Reset by Peer' network error. A Windows terminal server client can tell you that, for example, the Windows server has not allowed you to connect because it ran out of licences. In the worst case, I found that once a terminal server's connection limit had been reached rdesktop would pop up its window then simply disappear without any error diagnostics at all. The end result is that you must troubleshoot all of these sorts of connection problems from the Windows server end with the Event Log, which is not the easiest thing to do.
A wide range of features
Rdesktop now supports (don't hold your breath, it's a long list):
- 8/16/24-bit colour connections
- Sound redirection (play sounds from the server on your local PC)
- Clipboard redirection (copy and paste text to and from the remote server)
- Both RDP 4 and RDP 5 (RDP 4 doesn't support all the fancy options RDP 5 does)
- Connections to the 'real' console screen of a Windows server
- Specifying a program to start instead of the usual Explorer shell
- Passing username/password/domain information to automatically log in
- Support for many different keyboard layouts (multilingual)
- Several methods of full screen operation
- Support for running the remote desktop in custom screen resolutions (like 932x744)
- Miscellaneous performance enhancements tweaks that you can turn on and off
All of these features work, and some work extremely well. Running the Windows desktop at 24-bit colour really is as good as it sounds. When you log in, you get to hear the Windows sound as it loads your desktop (some might consider this a Bad Thing). Of particular note for sysadmins is the option to connect to the 'real' console of the remote server, which means they potentially no longer require pcAnywhere, VNC, or DameWare et al.
Using fullscreen mode is particularly satisfying. Rdesktop offers two methods to drive fullscreen mode. The first simply dumps a fullscreen window on your desktop and disables all your window manager keybindings. This is fine when using a GNU/Linux box as a shell to connect to the Windows server; all your traditional Windows key shortcuts get passed to the server. The second fullscreen method is to specify a window size identical to your X desktop screen resolution with the -g option, and to pass also the -K and -D options (-K tells your window manager to continue trapping special key combinations, and -D says to not 'decorate' the rdesktop window). This allows you to have a full screen window where most of your key shortcuts get passed to Windows (basically, anything that doesn't have special meaning to your window manager, like CTRL+C for copy, etc), but your window manager key bindings stay enabled. This means that in KDE and GNOME it is easy to put the full-screen window on one virtual desktop and use a hotkey to swap back and forth to your other virtual desktops with all your normal GNU/Linux applications. This is the method I use.
The bad news is that some of the features still require polish. One bug that I encountered, which is noted on rdesktop's sourceforge.net project page, is that occasionally rdesktop has difficulty properly connecting the Clipboard redirector -- usually when you disconnect and reconnect multiple times to the same session. This causes it to spew continuous error messsages to the console, and significantly impacted the performance of KDE on my local machine. Interestingly, while GNOME seemed unaffected by the stream of errors, the end result was the same on both: I could no longer copy and paste text until I logged out of Terminal Server and logged back in fresh.
One other minor nit to pick is the implementation of the automatic login feature. You specify a password as a command-line option to rdesktop. This means that anyone on your system who runs a `ps -ef` command will potentially see the full command line of rdesktop and hence your password. On GNU/Linux automatic login has been implemented cleverly so that the password shows up on the process list as simply a string of XXXXXXs. On Sun Solaris 8 and 9, however, the password is plainly visible. This means that on multi-user systems such as our SunRay server the automatic login feature constitutes an obvious security risk. I can only assume that Linux's better behaviour relates to some feature in the Linux kernel not available on the Solaris platform.
I have found rdesktop to be a remarkably stable, functional, and practical tool for integrating the work I do on my GNU/Linux laptop with our largely Windows-centric corporate structure and line-of-business applications (such as our trouble-ticket system). With the introduction of version 1.3.0 of rdesktop and its support for RDP 5, small businesses especially have been handed the tool that they have been waiting for to cost-effectively shift their infrastructure onto GNU/Linux. No more arguments about whether that one critical program will run on GNU/Linux or not: it doesn't have to!
Darryl Dixon is a senior Unix administrator for a New Zealand corporate. He is an RHCE, an MCSE, and an MCSA, and in a past life worked as a Windows NT Administrator for the same company he does today. He occasionally programs in Python and C, and is proud to have authored a few open-source tools that have been of practical use in mixed environments.