How Does This Remote Work?

As sad as it may seem, there are some applications and utilities I use in my Network Administrator position which are simply not available for PPC OS X or Linux that are essential to doing my job in a effective and efficient manner.  One in particular is managing our vSphere 5.5 virtual environment and infrastructure.  VMware's vSphere Web Client requires Adobe Flash (minimum version of 10.1.0), which is of course, not officially supported on the PPC architecture and hasn't been for sometime. Even if it was, I have a strong feeling it would perform poorly.

I decided to try out a few pieces of software that would allow me to connect either via VNC or RDP to other machines on our network and to other PPC machines at my humble abode.  The first one I attempted to use was the well-known and popular Remmina application, which I was surprised still supported the PPC architecture. Remmina is incredibly straightforward and has a unique array of settings you can adjust to best fit your needs for each remote session/device.  What I find most useful is the fact that you can save as many individual connections as necessary for each of the devices you would or might be needing to connect to while being able to maintain separate settings for each one, including resolution, color depth, performance, etc.  The VNC connection to my G4 PowerMac running Jessie works flawlessly, so I'll continue to use it for my VNC connections.

Upon trying to RDP into my Windows 8.1 machine, I would initially receive the login prompt, where I could input my username, password, domain, and accept the certificate, but from there, a simple generic error would appear right afterwards as such:

Not very useful, am I correct?  This was with the default Security setting of Autonegotiate under the connection's Advanced tab. By leaving the setting as is, Reminna should work with Windows 8.1 to figure out what security was to be used automatically whether that be NLA, TLS, or RDP.  Just as a test, I tried to set the Security to each of the 3 available individual options with different failed results. What I needed was a bit more information in order to determine the cause of the failure.  I decided to run Remmina from the terminal to watch for the output that would appear while trying to RDP to my 8.1 PC.  This is the more detailed error I received during the connection attempt:

SSL_read: Failure in SSL library (protocol error?)
Authentication failure, check credentials.
If credentials are valid, the NTLMSSP implementation may be to blame.

First of all, I love the error.  Seems like a bit of finger pointing. Anyways, based on that information, I figured it has something to do with Microsoft's NLA, or Network Level Authentication, which was a new feature for Windows RDP 6.0 made available as of Windows Server 2008 and Vista (Windows XP SP3 supports it as well now).  NLA requires users properly and successfully authenticate themselves before establishing the actual RDP session. As stated in the article above, this helps combat DDoS attacks because no resources are used on the remote server/device until authentication is successful.  Somebody could previously make an unprecedented number of connections to a remote device without needing to authenticate themselves thus using this as a way to consume all available resources on the remote device.

My initial thought was that perhaps it was an incomplete implementation of NLA in Remmina or a bug, so I downloaded and tested both rdesktop and freerdp.  Both are command line only with freerdp actually being a fork of rdesktop with supposedly better support for newer protocols such as NLA.  However, I received the exact same error message (verbatim actually) with both utilities as I was with Remmina.

At this point, I ended up spending quite a bit more time trying various things to overcome the issue and ended up deciding to go with a workaround for now by disabling NLA on my Windows 8.1 laptop.  You can do this under Control Panel -> System and Security ->  Allow Remote Access.  Under the window that appears, uncheck the option "Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)".  Again, the caveat being that disabling this will make the connection less secure, but for the meantime it will have to do.  Thankfully (sort of), this worked and I was able to RDP to the PC witih Remmina via my saved connection.  On the downside, the colors were way off and there was what seemed like a heavy blue tint to the display.  I tried adjusting the Color depth option to set it at the highest possible value of 32 bpp (True color) as well as trying to make RemoteFX work, but the results were again, exactly the same.  Here is a screenshot of what I'm talking about:

(Makes me think of this song)

Eventually, I tried rdesktop again (since I had disabled NLA on the Windows 8.1 PC), but this time with successful results all around!  Here is a screenshot of the resulting RDP window:

From the command line, I simply ran the following:rdesktop -u HarryPotter -d Hogwarts 192.168.10.1

Values have obviously been changed for security purposes. The -u is for username and the -d is for the domain name.  I could have passed in the password as well, but decided to let the connection ask me for it. The colors were near perfect to that of what I saw when actually sitting right in front of the PC. However, the default window size was a bit small. To be honest, I'm not sure what the dimensions were nor did I care to look. What I did care about was adjusting that default window size when starting the connection so that it would occupy the entire display of the PowerBook, which again, has a resolution of 1440x960.  Even if not the entire screen, perhaps a good portion of it. So as usual, I dove into rdesktop's man pages to see what other flags and options were available to make this happen.

To adjust the window size, you pass in the -g option (g for geometry!) or try out the -f option to have it start in full screen mode.  For the -g option, you can either pass in a percentage value, which is what I did first, or it pulls the value from the extended window manager hints property (a.k.a _NET_WORKAREA).

Here is a screenshot of the entire screen with a set screen size of 90% for the RDP session:

Based on what little I know, it appears the blue tint with Remmina is an implementation bug.  I'll probably look in the next day or two to see if the bug is out there and if it isn't I'll do my due diligence and file a bug report.

The application only uses between 10 - 15% and at times up to 20% of the CPU on my 1.67 GHz PowerBook, so impact is usually small and does not affect performance of other applications I have open.  Most of that CPU consumption is to redraw the screen as of course all actual applications on the remote session are running on the remote machine.  As I had mentioned earlier, what I really wanted to do was access the vSphere Web Client, which I can do in a Mozilla browser on the PC while still accessing all the applications I use on my Debian install.

Lastly, there are a few oddities I still need to work out with this setup.  The first being that when I initially remote into my PC, it brings up the login screen where I have to actually select the Other User option as it will not let me sign in automatically to my existing desktop session.  The Other User option already has my username entered (assuming because it was the last user to login) and once I type in the correct password, it connects me to my existing desktop session.  Secondly, I cannot run the session in full screen mode as I have not yet figured out how to successfully either exit the rdesktop application or change applications on my PowerBook as the Option (Alt) + Tab shortcut actually switches applications on my Windows machine. I'll play around with each of these and provide updates (good ones hopefully) in a future post.

Again, I have not researched the small possibility of somehow running Adobe Flash applications on PPC and have yet to play with any of the Flash alternatives such as Gnash or Sparkle that are available on Linux.  I'm not quite yet ready to try and tackle them at this current time.  If I do, I'll probably try it out first and use it only on my G5 as it has more adequate processing power and memory needed to provide somewhat smoother playback and performance.   My luck, is that by the time I do figure something out, VMware will have hopefully decided to rewrite the Web Client in HTML5, which should happen sooner rather than later.  I say that because even YouTube recently announced that HTML5 is now the default video playback format in most modern browsers.  Now that is something to be stoked about!